Ingestible event marker data framework

ABSTRACT

The ingestible event marker data framework provides a uniform, comprehensive framework to enable various functions and utilities related to ingestible event marker data (IEM data). The functions and utilities include data and/or information having an aspect of data derived from, collected by, aggregated by, or otherwise associated with, an ingestion event.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/498,396, filed on Apr. 26, 2017, now U.S. Pat. No. 11,217,342, whichis a continuation of U.S. patent application Ser. No. 12/522,249, filedon Jul. 6, 2009, which is the U.S. national phase entry of PCT PatentApplication No. PCT/US2009/049618, filed on Jul. 2, 2009, which is basedupon and claims the benefit of priority of U.S. Provisional ApplicationNo. 61/079,082, filed on Jul. 8, 2008, each of which is incorporatedherein in its entirety by reference.

FIELD OF THE INVENTION

The present invention relates generally to the technical fields ofingestible devices and communications. More specifically, and in variousexample embodiments, the present invention relates to a method, article,and system of generating, collecting, managing, distributing, andotherwise utilizing information associated with ingestible events andresponses to the ingestible events.

BACKGROUND

Information related to personal events is widely needed in variouspursuits. A personal event is an event that is specific to anindividual. Examples of personal events include onset of a physiologicparameter of interest, ingestion of a therapeutic agent, etc.

There are many instances where one may want to note a personal event.Examples of such instances include onset of one or more physiologicparameters of interest including appearance of disease symptoms,administration of medication, ingestion of certain types of foods,commencement of an exercise regimen, ingestion of certain substance,etc.

A variety of different methods and technologies have been developed tonote a personal event. For example, techniques have been developed inwhich individuals can manually record data in a log or physically enterdata via a computer device.

The accuracy of such notations may be dependent on the accuracy of datainput, the accuracy of proxies used as actual data substitutions, etc.As a result, inaccuracies may occur.

In one example, an individual may suffer from one or multiple healthconditions that require therapy with multiple medications. The multiplemedications may be prescribed according to an intricate dosing schedule.The complexities associated with multiple health conditions, multiplemedication therapies, and intricate dosing schedules may confuse thepatient, resulting in inaccurate data capture.

In one example, the individual may have physical or cognitive deficitswhich may result in difficulties inputting and capturing data. Theindividual may forget to enter the data, or may enter the dataincorrectly.

In one example, the individual may not wish to be inconvenienced andthus may intentionally refuse to enter the data. Conversely, theindividual may unintentionally or intentionally enter/record data whichis completely inaccurate. For example, the individual may receiveperiodic, prescheduled reminders to take some medication. The remindersare unable to take into account actual ingestion of the medication. Ifthe individual has already taken the medication, the reminder is bothmoot and likely to inconvenience the individual. If the medication hasnot been taken, an inconvenient or unneeded reminder or alert may promptthe user to enter data or send a message advising that the medicationhas been taken just to quell the alarm while not actually taking themedication. The individual may intentionally leave out portions of thedata.

In one example, proxies for data and information may also be inaccurate.For example, “intelligent” medication containers may contain microchipsthat sense opening of the medication container. From the sensed act ofopening the container, an inference may be drawn that medicationassociated with the medication container has been ingested. Theinference may be inaccurate, however, as medication is not necessarilyingested by virtue of opening a medication container.

The above-instances may ripen into further issues if particular partiesbesides the individual wish to use the individual's personal event data.Examples of users and potential users (sometimes collectively referredto herein as “party” or “parties”) of personal event data include familyand professional caregivers; communication companies; governmentagencies, e.g., agencies associated with government provided healthcarecoverage; private insurance providers; Food and Drug Administration(FDA); Drug Enforcement Administration (DEA); US Bureau of Alcohol,Tobacco, and Firearms (ATF); care providers; medical devicemanufacturers; patients; clinicians; pharmaceutical manufacturers;pharmacies; web communities; software providers; marketing and financialanalysts; and insurance companies.

Competing interests may exist between an individual's privacy interestsin personal event data and the acquisition and appropriation of thepersonal event data by third parties.

Further, various parties may have a compelling interest in receipt ofaccurate and comprehensive data, e.g., useful data, either in isolatedform (data germane to a particular individual) or empirical form(aggregated data from various sources, various individuals, variouspersonal events of an individual, etc.)

In many circumstances, however, accurate personal event data are notavailable. The party may have access to faulty data or a crudeapproximation of the information sought, as discussed above. Thus, theparty must rely on such crude proxies to formulate a conclusion. Itfollows, then, that such conclusions may themselves be skewed orinaccurate. Actions taken in reliance on such conclusions may provemisguided, error-prone, and/or harmful.

To illustrate, a healthcare provider or family member may receive amessage from a patient indicating that the patient has taken themedication when, in fact, the patient is merely providing the messagewithout having actually ingested the medication. If the healthcareprovider notices changes in the patient's symptoms in close temporalproximity to receipt of the flawed information suggesting medicationingestion, the healthcare provider may mistakenly conclude that thepatient's symptoms are a result of the medication ingestion. Based onthe mistaken conclusion, the healthcare provider may adjust themedication dosage in an attempt to alleviate the symptoms, perhaps tothe patient's detriment.

Of note, the more widely propagated and aggregated the inaccurate data,the more prolific the spread of and reliance on error-associated dataand conclusions drawn therefrom.

In addition, recipients of the personal event data may wish to timelyreceive and utilize such information via a user-friendly, reliable andsophisticated means. The recipients may wish to receive and/or utilizeinformation in discrete areas, integrate the personal event informationwith other data, and use the personal event information for variouspurposes.

Examples of various purposes include refining and optimizing data suchas patient population data; incentivizing individuals or groups based onpersonal event data, e.g., ingestible event marker data (“IEM data”);corroborating and advancing decisions; supporting stakeholders'decisions; using IEM data in personalized products and services, e.g.,user applications on a mobile telephone; auto refilling prescriptionmedications; managing pharmaceutical life cycle systems and controlledsubstances; compiling and delivering IP news and information feeds;accessing open sources of anonymized patient population data;determining eligibility and approval for refills, insurance coverage,etc.; using patient tools; participating in social network systems;analyzing aggregated data to derive and/or generate predictiveinformation; supporting and enabling financial transactions; identifyingdirect and indirect causal failure points in treatment and predictcorrective action; and providing dynamic, accuratecalendaring/scheduling functions.

Finally, parties may also wish to access personal event data inconjunction with existing systems, e.g., commercial systems such asautomated pharmacy systems, banking and financial systems, etc.

As can be seen, methods and systems are needed to seamlessly collect,manage, and distribute personal event data to various parties andsystems.

Therefore, there is a need for controlled collection, management, anddelivery of accurate personal event data to multi-profile parties forvarious purposes.

BRIEF SUMMARY OF THE INVENTION

The ingestible event marker data framework provides a uniform,comprehensive framework to enable various functions and utilitiesrelated to ingestible event marker data (IEM data). The functions andutilities include data and I or information having an aspect of dataderived from, collected by, aggregated by, or otherwise associated with,an ingestion event. In one example, the IEM data are generated via aningested device. The term “ingested device” includes any device,mechanism, structure, combined structure, or object capable of ingestionby a human subject or a non-human subject.

The IEM data framework is highly scalable and integratable with variousexisting systems, e.g., systems having computer-related component(s).Specific examples of such systems include pharmacy systems,communication systems, financial and banking systems, school systems,medical systems, government agencies, web communities, and personalcomputer systems. Such existing systems are herein collectively referredto as “commercial systems”.

The IEM data framework enables multiple and various types ofimplementations. The implementations include various configurations ofhardware, software, communication components, and/or data. For example,in one aspect, the IEM data framework is implemented with a basiccomplement of core components; namely, ingestible event marker data; ahub to receive the ingestible event marker data; and at least oneingestible event marker data system to receive, directly or indirectly,the ingestible event marker data from the hub.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 provides a diagrammatic representation of a communicationenvironment including an IEM data framework, according to oneembodiment.

FIG. 2 provides a diagrammatic representation of the IEM data frameworkof FIG. 1, according to one embodiment.

FIG. 3 illustrates IEM data and an IEM data environment associated withthe IEM data framework of FIG. 2, according to one embodiment.

FIG. 4 illustrates a hub associated with the IEM data framework of FIG.2, according to one embodiment.

FIG. 5 illustrates exemplary IEM data systems associated with the IEMdata framework of FIG. 2, according to one embodiment.

FIG. 6 illustrates an exemplary IEM data framework having a feedbackloop system, according to one embodiment.

FIG. 7 illustrates an exemplary IEM data framework having a decisionsupport system, according to one embodiment.

FIG. 8 illustrates an exemplary IEM data framework having auto refillsystem, according to one embodiment.

FIG. 9 illustrates an exemplary IEM data framework having patient tools,according to one embodiment.

FIG. 10 illustrates an exemplary IEM data framework having a behavioralmedicine system, according to one embodiment.

FIG. 11 illustrates an exemplary IEM data framework having an incentivesystem, according to one embodiment.

FIG. 12 illustrates an exemplary IEM data framework having apersonalized commercial products/services system, according to oneembodiment.

FIG. 13 illustrates an exemplary IEM data framework having an autobilling system, according to one embodiment.

FIG. 14 illustrates an exemplary IEM data framework having a trackingsystem, according to one embodiment.

FIG. 15 illustrates an exemplary IEM data framework having aninterdiction system, according to one embodiment.

FIG. 16 illustrates an exemplary IEM data framework having asubscription system, according to one embodiment.

FIG. 17 illustrates an exemplary IEM data framework having an ingestibleevent marker data collection system, according to one embodiment.

FIG. 18 illustrates an exemplary IEM data framework having an approvalsystem, according to one embodiment.

FIG. 19 illustrates an exemplary IEM data framework having a forecastingsystem, according to one embodiment.

FIG. 20 illustrates an exemplary IEM data framework having a financialsystem, according to one embodiment.

FIG. 21 illustrates an exemplary IEM data framework having an ingestibleevent marker data phone system, according to one embodiment.

FIG. 22 illustrates an exemplary IEM data framework having a socialnetwork system, according to one embodiment.

DETAILED DESCRIPTION 1.0 Overview 2.0 Ingestible Event Marker (IEM) DataFramework

2.1 IEM Data

-   -   2.1.1 IEM Data Environment        -   2.1.1.1 IEM Data Source Devices        -   2.1.1.2 Products        -   2.1.1.3 Events        -   2.1.1.4 Patient Specific Parameters        -   2.1.1.5 IEM Data Algorithms        -   2.1.1.6 Storage Repositories        -   2.1.1.7 Other IEM Data Sources

2.2 Hub

2.3 IEM Data Systems

-   -   2.3.1 Feedback Loops    -   2.3.2 Decision Support Systems    -   2.3.3 Auto Refill Systems    -   2.3.4 Patient Tools    -   2.3.5 Behavioral Medicine Systems    -   2.3.6 Incentive Systems    -   2.3.7 Personalized Commercial Products/Services    -   2.3.8 Auto Billing Systems    -   2.3.9 Tracking Systems    -   2.3.10 Interdiction Systems    -   2.3.11 Subscription Systems    -   2.3.12 IEM Data Collection Systems    -   2.3.13 Approval Systems    -   2.3.14 Forecasting Systems    -   2.3.15 Financial Systems    -   2.3.16 IEM Data Phone    -   2.3.17 Social Network System

3.0 IEM Data Framework Method 4.0 IEM Data Framework Article 5.0 IEMData Framework System 1.0 Overview

The ingestible event marker (IEM) data framework provides an integrated,seamless solution to enable the collection, management, distribution,and utilization of IEM data. The versatile IEM data frameworkfacilitates integration and implementation of the IEM data with existingdata and utilization of the IEM data with existing systems, i.e.,commercial systems. The information and communication systems includediscrete systems, cross-configured systems, and hybrid systems.

Broadly, various aspects of the IEM data framework include a basiccomplement of core components, e.g., IEM data; a hub; and at least oneIEM data system. Any one or a combination of these core components iscapable of interoperation, communication, and/or integration withvarious components of other information/communication systems. The terms“data” and “information” are used interchangeably herein.

The IEM data include information about an ingestion event, informationabout a response to the ingestion event, or both. The information aboutan ingestion event may include, for example, information about theingestion event of a medication or set of medications. The informationabout a response to the ingestion event may include, for example,physiologic parameter(s) such as a physiologic status or physiologicchange event based on the ingestion event. A physiologic status may be,for example, a heart rate, blood pressure measure, etc., ascertained inclose temporal proximity to the time of ingestion of medication (and,therefore, likely to be influenced by or a result of ingestion of themedication.)

Examples of IEM data include data ingestion time(s) of medication,identification of the type(s) of medication ingested at a particulartime, the dosage amounts of medication ingested at a particular time,etc.

Typically, the IEM data may be generated and I or communicated via aningestible device such as an ingestible event marker (IEM), whichgenerates and communicates data associated the ingestion event. The IEMmay be associated, for example, with a receiver, i.e., a device capableof receiving the IEM data on ingestion and further capable of measuringadditional IEM data on response to the ingestion event(s). The IEM andthe receiver are discussed in detail hereinafter. In various aspects,the ingestible event data may originate from multiple ingested eventmarkers. In various aspects, the IEM data may be communicated directlyfrom the IEM to a device other than the receiver, e.g., an IEM businesssystem adapted to receive the IEM data directly from the IEM via acommunication channel.

In various aspects, the IEM data may be associated with other data,e.g., combined with data related to events other than an ingestion eventor response(s) to an ingestion event. Some examples of other data aredata associated with various medical devices and data associated withconsumer and personal devices such as intelligent devices/appliances.All are discussed in greater detail hereinafter.

In various aspects, the IEM data may be associated with an IEM dataenvironment and I or commercial systems.

In various aspects, the IEM data may be associated with a uniqueidentifier, e.g., sample data reflective of physiologic patternsassociated with a particular individual such as heart rate variability,breathing rate, and I or heart rate (ECG) patterns. For example, aportion or all of the IEM data may be compared with a unique identifiergenerated by or stored on the receiver.

The hub includes any hardware device, software, and/or communicationscomponent(s), as well as systems, subsystems, and combinations of thesame which generally function to communicate the IEM data. Communicationof the IEM data includes receiving, storing, manipulating, displaying,processing, and/or transmitting the IEM data.

In various aspects, the hub also functions to communicate, e.g., receiveand transmit, non-lEM data. Non-lEM data includes non-lEM physiologicdata. One example is cardiac data generated by a separatecardiac-related device such as an implanted pacemaker and communicatedto the hub directly or indirectly, e.g., via the receiver.

Broad categories of hubs include, for example, base stations, personalcommunication devices, and mobile telephones.

For example, the hub includes a software application associated with amobile telephone of a patient. The application and mobile telephonefunction to receive IEM data from a receiver, which, in turn, receivesthe IEM data from an ingestible device ingested by the patient. The hubstores, manipulates, and/or forwards the IEM data, alone or incombination with other data, to an IEM data system.

The IEM data systems include any hardware device, software, and/orcommunications component, as well as systems and subsystems of the same,which generally function to provide a service or activity related to theIEM data. The IEM data systems, for example, collect, manipulate,calculate, transmit, receive, store, and I or communicate at least aportion of the IEM data.

Each IEM data system may be built around predefined function(s) orservice(s) and may be enabled via the IEM data framework.

One or more IEM data systems may be integrated, interoperate,intercommunicate or otherwise share or further the collection,management, distribution/dissemination, billing or other activitiesrelated to IEM data. One example of an IEM data system is a feedbackloop system to refine and optimize IEM data and other data, e.g.,medical database data.

Various aspects of the IEM data framework provide on-demand, accurateand efficient services with respect to provision and utilization of IEMdata, while reducing redundancies, errors, and inaccuracies associatedwith personal event data that are sometimes found in the prior art.Various aspects of the IEM data framework further ensure generation andcommunication of accurate IEM data in a timely manner.

Further, the IEM data framework is applicable to any communicationenvironment. Communication environments include any environment havingtherein, or associated with, data or communication of data.

Various aspects of the IEM data framework utilize the IEM data, the hub,and one or more IEM data systems to enable useful, secure, and efficientuse of the IEM data among multi-profile parties in one or variouscommunication environments.

FIG. 1 provides a diagrammatic representation of communicationenvironment 100 including an IEM data framework 102, according to oneembodiment. The communication environment 100 may further include, forexample, an IEM data environment 104 and one or more commercial systems106.

Communication environment 100 includes any environment having therein,or associated with, data or communication of data. Communicationincludes any method, act, or vehicle of communication, and/orcombinations thereof. For example, communication methods include manual,wired, and wireless, etc. Wireless technologies include radio signals,such as x-rays, ultraviolet light, the visible spectrum, infrared,microwaves, and radio waves, etc. Wireless services include voice andmessaging, handheld and other Internet-enabled devices, data networking,etc.

Vehicles of communication include the Internet, wired channels, wirelesschannels, communication devices including telephones, computers, wire,radio, optical or other electromagnetic channels, and combinationsthereof, including other devices and/or components capable of/associatedwith communicating data. For example, the communication environmentsinclude in-body communications; various devices; various modes ofcommunications such as wireless communications, wired communications,and combinations of the same, etc.

In-body communications include any communication of data or informationvia the body, i.e., communication via or associated with inter-bodyaspects, intra-body aspects, and a combination of the same. For example,inter-body aspects include communications associated with devicesdesigned to attach to a body surface. Intra-body aspects includecommunications associated with data generated from within the body,e.g., by the body itself or by a device implanted, ingested, orotherwise locatable in, or partially in, the body.

Communications include and/or may be associated with software, hardware,circuitry, various devices, and combinations thereof.

The devices include devices associated with IEM data generation,transmission, reception, communication, etc. The devices further includevarious implantable, ingestible, insertable, and I or attachable devicesassociated with the human body or other living organisms. The devicesfurther include multimedia devices such as telephones, stereos, audioplayers, PDA's, handheld devices, and multimedia players.

Wireless communication modes include any mode of communication betweenpoints that utilizes, at least in part, wireless technology includingvarious protocols and combinations of protocols associated with wirelesstransmission, data, and devices. The points include, for example,wireless devices such as wireless headsets; audio and multimedia devicesand equipment, such as audio players and multimedia players; telephones,including mobile telephones and cordless telephones; and computers andcomputer-related devices and components, such as printers.

Wired communication modes include any mode of communication betweenpoints that utilizes wired technology including various protocols andcombinations of protocols associated with wired transmission, data, anddevices. The points include, for example, devices such as audio andmultimedia devices and equipment, such as audio players and multimediaplayers; telephones, including mobile telephones and cordlesstelephones; and computers and computer-related devices and components,such as printers.

The IEM data framework 102 enables exchange, transmission, receipt,manipulation, management, storage, and other activities and eventsrelated to IEM data. Such activities and events may be contained withinthe IEM data framework 102, partially integrated with the IEM dataframework 102, or associated with externalities, e.g., activities,systems, components, and the like which are external to the IEM dataframework 102. Externalities include, for example, the IEM dataenvironment 104 and commercial systems 106, either or both of which mayalso be integral to, or partially integrated with, the IEM dataframework 102.

The IEM data environment 104 includes any source of information or data,including remote computer systems, local computer devices, etc. Theinformation or data may comprise IEM data in whole or in part. Theinformation or data may also be independent of the IEM data, e.g., maybe capable of aggregation and I or integration with the IEM data.

The commercial systems 106 include various existing systems that utilizeone or various types of data to accomplish a particular purpose. Oneexample of a commercial system is a computerized pharmacy systemutilized in a pharmacy. The computerized pharmacy system may function toautomatically, e.g., electronically, receive prescriptions, verifypatient and prescription information, verify insurance coverage, processthe prescription order, and generate an invoice.

The IEM data framework 102, the IEM data environment 104, and thecommercial systems 106 are discussed in greater detail hereinafter.

2.0 IEM Data Framework

FIG. 2 provides a diagrammatic representation of the IEM data framework102 of FIG. 1, according to one embodiment. The IEM data framework 102includes IEM data 200, hub 202, and one or more IEM data systems 204.

The IEM data 200 include data associated with an ingestion event, i.e.,an act of ingestion. Additionally, the IEM data 200 may include, beincluded in, or be combined with data from other systems or sources,e.g., medical devices, local or remote computer devices and systems,etc. An example of the IEM data 200 is data having an identification ofthe type of an ingested medication and the time at which the medicationwas ingested.

The hub 202 includes any hardware, software, and I or communicationscomponent(s) in any combination/configuration, which generally functionto communicate the IEM data 200. One example includes communicating theIEM data 200 to the IEM data systems 204. For example, the hub 202receives the IEM data 200 from an ingested device and forwards the IEMdata 200, alone or in combination with other data from other sources, toan IEM data system 204.

The IEM data systems 204 provide discrete services and/or activitiesrelated to the IEM data 200. The discrete services and I or activitiesinclude, for example, propagation of information, data, etc., to aparticular user, or group of users, via various system componentconfigurations, etc.

In one example, an auto refill system receives IEM data 200 from the hub202. The IEM data 200 include an indication that the last remaining pillof a prescription has been ingested. The auto refill system uses thisinformation to contact a local or remote data resource having refillinformation, verify the refill information, and automatically transmit arequest to a pharmacy system (commercial system) for refill of theprescription.

2.1 IEM Data

The ingestible event marker (IEM) data 200 are associated with at leastone of an ingestion event and a response to the ingestion event. Theingestion event may be associated with, for example, data related to andI or gathered during transit through the alimentary system, e.g., oralcavity, pharynx, esophagus, stomach, small intestine, large intestine,anus, etc. Examples of IEM data include an ingestion time,identification of ingested substance, expiration date of an associatedmedication, dosage of an ingested substance, etc. The information aboutan ingestion event may include, for example, information about theingestion event of a medication or set of medications. The informationabout a response to the ingestion event may include, for example,physiologic parameter(s) such as a physiologic status or physiologicchange event based on the ingestion event. A physiologic status may be,for example, a heart rate, blood pressure measure, etc., ascertained inclose temporal proximity to the time of ingestion.

In various aspects, the IEM data 200 typically may be generated via oneor more ingestible event markers (IEMs), discussed hereinafter indetail. The generation of IEM data via multiple IEMs ensurescomprehensive data reporting, e.g., data generated from multipleingestion events of multiple IEMs over a time interval, data generatedfrom multiple IEMs ingested at approximately the same time, etc. In thismanner, comprehensive IEM data may be provided.

In various aspects, the IEM data may be communicated to, i.e., receivedby, a receiver. The receiver may be embodied in various ways, includingan implantable device, a semi-implantable device such as a subcutaneousdevice, and an externally-applied device such as a personal signalreceiver. One example of a personal signal receiver is a “patch”receiver which may be removably affixed to the individual's person,apparel, etc.

In various aspects, the IEM data 200 can be associated with other data,e.g., a personal event not associated with an ingestion event or aresponse to an ingestion event. A personal event includes any parameteror circumstance associated with a person, e.g., any event associatedwith ingestion, inhalation, injection, implantation, insertion, and/orimbibing of a device, substance, liquid, etc. A personal event furtherincludes any event associated with personal data, e.g., a physiologicparameter such weight.

In various aspects, the IEM data may be associated with a uniqueidentifier, e.g., heart rate variability, breathing rate, and I or heartrate (ECG) patterns associated with a particular individual. The uniqueidentifier may be variously embodied. One example is a personalidentifier assigned to an individual, e.g., an alphanumeric code, etc.Another example is a unique identifier reflective of an individualtrait, such as a physiologic pattern.

To illustrate, a patient may ingest an IEM (discussed hereinafter)integrated with medication. The IEM may communicate IEM data to areceiver such as a patch receiver (discussed hereinafter). The data mayinclude, for example, a unique identifier which may be compared to dataassociated with the receiver for validation purposes.

In one scenario, the IEMs associated with medication prescribed for aparticular patient may each be encoded and deployed with correspondingunique identifiers. The unique identifier may be, for example, apredetermined physiologic data sample associated the particular patient.Various physiologic data samples include a data sample reflective of theparticular patient's heart rate variability, a data sample reflective ofthe particular patient's breathing rate, a data sample reflective of theparticular patients heart rate (ECG) patterns, etc.

When the receiver is affixed or otherwise associated with an individual,programming logic associated with the receiver may receive actual datasamples of the individual, e.g., from data sources such as heartdevices, etc. The receiver may communicate the actual data samplesreceived from the data sources and the unique identifier(s) receivedfrom the IEM(s) to a computer-related device, e.g., a server, which maycompare the actual data samples of the individual with the uniqueidentifier to verify that the medication was actually ingested by theparticular patient for whom it was prescribed. In various aspects,predetermined actions based on the verification outcome may be taken,e.g., alerts may be sent to a device associated with the prescribingphysician, etc.

2.1.1 IEM Data Environment

In various embodiments, IEM data 200 are generated, received, gathered,etc., from one or a variety of sources and comprise various structures,content, types, etc. The IEM data environment includes at least one ofan IEM data source device, products, events, patient specificparameters, IEM data algorithms, and storage repositories. The sourcesinclude, for example, various devices, storage repositories, and systemscapable of generating, identifying, gathering or otherwise producingdata related to ingestion, the ingestion environment, e.g., thealimentary system of a human subject or non-human subject and/or otherpersonal events. The types include, for example, raw data, processeddata, aggregated data, combined data, data from various sources, etc.The processed data include, for example, data processed according to avariety of methods, e.g., algorithms such as IEM data algorithmsdiscussed below.

FIG. 3 illustrates IEM data environment 104 associated with the IEM dataframework 102 of FIG. 2, according to one embodiment. The IEM dataenvironment 104 includes, for example, IEM data source devices 300,products 302, events 304, patient specific parameters 306, IEM dataalgorithms 308, storage repositories 310, and other sources 312, such asa multisensor lead 312 a.

2.1.1.1 IEM Data Source Devices

The ingestible event marker (IEM) data source devices 300 include, forexample, devices capable of gathering, collecting, generating,receiving, storing and/or transmitting, etc., IEM data. One example ofsuch a device is a microchip capable of or otherwise enabling orfacilitating the collection, generation, receipt, transmission, etc., ofdata. Such a microchip may be integrated or associated with the IEM datasource devices 300. The IEM data source devices 300 may be embodied, forexample, as ingestible devices 300 a, receivers 300 b, and/or healthdevices 300 c.

In various aspects, IEM data may be related to various devices. Forexample, a device may be an ingestible device, an inhalable device, aninjectable device, an implantable device, an insertable device, and animbibable device. The foregoing may be embodied, for example, as amicrochip alone or in combination with other structural components, eachcapable of at least one of ingestion, inhalation, injection,implantation, insertion, and imbibement by a human body or a non-humanbody.

The ingestible device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a medication,e.g., a pill (refer to IEM system, infra).

The inhalable device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a device. Theinhalable device is capable of ascertaining parameter(s) associated withinhalation, e.g., measuring or tallying doses of an inhalant. Theinhalable device may also comprise, for example, an inhalable microchipused to ascertain parameter(s), e.g., inhalation time, identify aninhaled substance, etc.

The injectable device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a device. Theinjectable device is capable of ascertaining parameter(s) associatedwith injection, e.g., time of injection, identification of an injectedsubstance, etc. In various aspects, the injectable device is capable ofinjection into a human body or a non-human body, e.g., injection intothe circulatory system of a human body.

The implantable device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a device. Theimplantable device is capable of ascertaining parameter(s) associatedwith implantation, e.g., time of implantation, physiologic parameterssuch as heart rate, EKG data, activity management data, temperature,galvanic skin response data, respiratory data, fluid status data, heartrate variability, etc.

In one aspect, the implantable device is embodied as an implantablereceiver, supra, for receiving various data. The implantable receivermay also process, store, transmit, etc. the data. Various otherimplantable devices include, for example, heart monitors and the likehaving a microchip to ascertain parameter(s), e.g., heart rate, heartpressure, etc.

The insertable device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a device. Theinsertable device is capable of ascertaining parameter(s) associatedwith insertion, e.g., time of insertion, physiologic parameters suchenvironmental content/fluid identification, etc. In one aspect, theinsertable device is embodied as a microchip mechanically associatedwith a suppository for rectal insertion, vaginal insertion, etc.

The imbibable device may comprise, for example, a microchip. Themicrochip may be independently deployed. The microchip may also beattached to, embedded in, or otherwise integrated with a substance,e.g., a potable solution or fluid such as a beverage, etc. The imbibabledevice is capable of ascertaining parameter(s) associated with imbibing,e.g., time of drinking, physiologic parameters such as environmentalcontent I fluid identification, etc. In one aspect, the imbibable deviceis embodied as a microchip and imbibed together with a beverage. Thebeverage may aid in swallowing, may be used as a medication, etc.

Further, the IEM data may be associated with administration of atherapeutic agent, etc. For example, administration includes, but is notlimited to, parenteral administration, i.e., administration in a mannerother than through the alimentary system, such as by intravenous orintramuscular injection or inhalation.

In some aspects, the devices are capable of ingestion, i.e., entry intothe alimentary system of a human body or a non-human; inhalation (eitherthe device or a substance associated with the device, e.g., a nasalinhalant). In various aspects the devices are capable of injection,insertion, implantation and/or imbibing, etc., into/by a human body or anon-human body.

The ingestible devices 300 a gather I collect I generate IEM data viavarious methods, e.g., ingestion timing, contact with alimentary systemsubstances, sampling, etc. Further, various ingestible event marker datasource devices 300 communicate the IEM data via various methods, e.g.,wireless methods, conductive methods via body tissue, etc. The followingare examples of the ingestible devices 300 a.

A pharma-informatics system described in PCT/US2006/016370, filed Apr.28, 2006, includes compositions, systems and methods that allow for thedetection of the actual physical delivery of a pharmaceutical agent to abody are provided. Embodiments of the compositions include an identifierand an active agent.

An IEM system described in PCT/US2008/52845, filed Feb. 1, 2008,includes an ingestible event marker (IEM) and a personal signalreceiver. Aspects of the IEM include an identifier, which may or may notbe present in a physiologically acceptable carrier. The identifier ischaracterized by being activated upon contact with a target internalphysiological site of a body, such as digestive tract internal targetsite. The personal signal receiver is configured to be associated with aphysiological location, e.g., inside of or on the body, and to receive asignal of the IEM. During use, the IEM broadcasts a signal which isreceived by the personal signal receiver.

The IEM data associated with the IEM system include personal data, e.g.,physiologic data generated by the IEM. Examples are derived metrics,e.g., processed physical data to derive various metrics such as time ofingestion data; combined metrics, e.g., derived metrics combined withother derived metric data such as time of ingestion data combined withdata identifying the ingested substance; and IEM data, e.g., derivedmetrics and/or combined metrics aggregated with various physiologic datasuch as time of ingestion data combined with data identifying theingested substance and physiologic data such as ECG data, temperature,etc.

A controlled activation ingestible identifier described inPCT/US07/82563, filed Oct. 17, 2007, includes ingestible compositionssuch as pharma-informatics enabled compositions. The controlledactivation ingestible identifiers include a controlled activationelement that provides for activation of the identifier in response tothe presence of a predetermined stimulus at a target site of interest.

A life cycle pharma informatics system described in U.S. PatentApplication Ser. No. 61/034,085, filed Mar. 5, 2008 includes RFID andconductive communications technology combined with medication and/ormedication packaging such that the medication can be tracked for theduration of its existence. The system further allows in-body datatransmissions while addressing the potential privacy and signaldegradation concerns associated with RFID technology.

The IEM data receivers 300 b include devices capable of receipt of IEMdata 200. Receipt may be, for example, via wireless or wired channels,etc. The IEM data receiver 300 b may also transmit or otherwise forwarddata. In various aspects, the IEM data receiver 300 b may perform,facilitate, or enable various other functionalities related to the IEMdata 200 and/or other data. In various aspects, the IEM data receiver300 b may be attachable, implantable, semi-implantable or otherwiseassociated with a human body or a non-human body.

The IEM data receiver 300 b include personal signal receivers such aspatch receivers, e.g., removably attachable externally to a human bodyor a non-human body; subcutaneous devices; implantable devices; externaldevices, i.e., devices which are not designed for attachment or otherpermanent or semi-permanent contact with the body, e.g., a mobiletelephone. The following are examples of the IEM data receiver 300 b.

The IEM system, PCT/US2008/52845, supra, includes an ingestible eventmarker (IEM) and/or a personal signal receiver.

An active signal processing personal health signal receiver described inPCT/USO7/24225, filed Nov. 19, 2007, includes a receiver associated witha body, e.g., located inside or within close proximity to a body,configured to receive and decode a signal from an in vivo transmitterwhich is located inside the body.

The health devices 300 c include multiple devices (and methodsassociated with the devices) associated with the IEM data 200. Thehealth devices 300 c, for example, may gather, collect, aggregate,store, transmit, receive, or otherwise communicate data, including theIEM data 200.

Communication may be, for example, via wireless or wired channels, etc.The IEM data receiver may also transmit or otherwise forward data. Invarious aspects, the IEM data receiver 300 b may perform, facilitate, orenable various other functions related to the IEM data and I or otherdata. Examples include functions to store data, process data, etc.

In various aspects, the health device 300 c may be attachable,implantable, semi-implantable or otherwise associated with a human bodyor a non-human body. For example, “intelligent” devices such asintelligent scales, intelligent blood pressure cuffs, intelligentrefrigerators, etc., may be integrated in various configurations. Asused herein, the term “intelligent devices” refers to one or moredevices capable of generating and I or communicating data, e.g.,wirelessly transmitted data, via a communication channel to adestination.

2.1.1.2 Products

IEM data 200 also includes IEM data related to products 302. Theproducts 302 include, for example, an ingestible device/pharmaceuticalproduct 302 a. One example of an ingestible device/pharmaceuticalproduct 302 a is an IEM mechanically associated with medication. The IEMmay be mechanically associated with the medication in various ways,including externally affixed to the medication, partially integratedwith the medication, and wholly integrated with the medication.

The IEM may be affixed via various means, e.g., with various adhesive orformulated substances. The IEM may be associated with the medication atvarious phases, e.g., during a medication manufacturing process, atvarious points in time after a medication manufacturing process, etc.

2.1.1.3 Events

IEM data 200 further includes data related to events 304, e.g., personalevents, event parameters, etc. Further examples include time ofingestion of a medication, dosage and identity of medication taken attime of ingestion, etc. Events may include physiologic events, e.g.,respiration rate; environmental events, e.g., time of day; usage events,e.g., ingestion of a medication, use of a cardiac resuscitation device,etc.

2.1.1.4 Patient Specific Parameters

IEM data 200 still further includes data related to patient specificparameters 306, e.g., individualized patient data 306 a pertaining to anindividual patient and multiple patient data 306 b pertaining tomultiple patients. Examples of patient specific parameters includephysiologic data, etc. Multiple patient data include aggregated patientdata, patient population data, e.g., combined patient data whichincludes various predetermined aspects of data regarding at least onepatient and excludes data tending to identify a particular patient or anaspect in which the patient has a privacy interest, e.g., name, age,diagnosis and/or other data which the patient wishes to retain asconfidential and/or undisclosed to the public.

2.1.1.5 IEM Data Algorithms

IEM data 200 also includes data related to IEM data algorithms 308,e.g., raw data, processed data, or a combination of the same, whichundergo processing. In one example, the IEM data 200 have one or morealgorithms applied thereto, with processed data as an output. The data,for example, includes individualized patient data 306 a and multiplepatient data 306 b, e.g., patient population data.

The IEM data algorithms may be related to aspects such as dataprocessing associated with the IEM data 200 generated by one or moreingestible devices, e.g., an IEM system.

With respect to IEM data processing associated with an ingestibledevice, aspects include, for example, transmission of the IEM data 200,IEM data processing associated with a receiver, and IEM datapost-processing aspects.

Transmission aspects of IEM data and algorithms may include, forexample, modulation schemes, coding, and error code aspects.

The transmission aspects include, for example, analog, digital, spreadspectrum, combinatorial, and contention avoidance.

The analog transmission aspects include, for example, amplitudemodulation, single sideband modulation, frequency modulation, phasemodulation, quadrature amplitude modulation, and space modulationmethods, etc.

The digital transmission aspects include on/off keying, frequency-shiftkeying, amplitude-shift keying, phase-shift keying, e.g., binaryphase-shift keying, quadrature phase-shift keying, higher order anddifferential encoded, quadrature amplitude modulation, minimum shiftkeying, continuous phase modulation, pulse-position modulation, trelliscoded modulation, and orthogonal frequency-division multiplexing.

The spread spectrum transmission aspects include, for example, frequencyhopping spread-spectrum and direct-sequence spread spectrum.

The combinatorial transmission aspects include, for example, binaryphase shift-keying with carrier frequency modulation.

The contention avoidance transmission aspects include, for example,duty-cycle modulation and carrier frequency modulation.

The coding aspects include, for example, wake-up schemes, preambleschemes, data packet schemes, and error code schemes.

The wake-up schemes include, for example, multi-tone schemes and chirpschemes.

The preamble schemes include, for example, unique identifier for packetstart schemes.

The data packet schemes include, for example, data related to pill type,pill expiration, manufacturer, lot number, amount, prescribingphysician, pharmacy, etc.

The error code schemes include, for example, repetition schemes, parityschemes, checksums, cyclic redundancy checks, hamming distance schemes,and forward error correction schemes, e.g., Reed-Solomon codes, binaryGolay codes, convolutional codes, turbo codes, etc.

With respect to IEM data processing and the receiver, considerations maybe given to, for example, position, energy conservation schemes, carrieridentification, decoding and error correcting.

The position of the receiver includes, for example, the stomach, theside and the xiphoid.

The energy conservation schemes include schemes for a periodic wake-up,e.g., to sense IEM wake-up such that energy, e.g., battery resources, isconserved during non-awake periods.

The carrier identification aspects include, for example, Fouriertransform analysis, e.g., fast Fourier transform and discrete Fouriertransform, phase locked loop, filter bank, match filter, andcombinatorial such as use of previous knowledge about frequency totune-in.

The decoding aspects and error correcting aspects include, for example,the above-iterated aspects.

With respect to IEM data post-processing, aspects include, for example,pill detection, e.g., multiplicity of identification and count in timeaspects, adherence metrics, etc.

With respect to IEM data processing associated with physiologicparameter metrics, aspects include, for example, electrocardiogram (EKGor ECG), impedance, acceleration, optical, pressure, temperature, sound,biochemical/biological, weight, position, derived electromyography(EMG), and electroencephalography (EEG).

IEM data processing related to EKGs includes, for example, compressiondata, e.g., wavelet and ICA/PCA, R-wave detection such asHamilton-Tompkins, etc., heart-rate variability, e.g., SDNN, standarddeviation in a 24 hour period, standard deviation of consecutive fiveminute periods, foot print heart rate versus standard heart rate,distribution-based histogram, etc., arrhythmia, and respiration, e.g.,principal axis modulation.

IEM data processing related to impedance includes, for example,respiration, fluid status, Galvanic skin response, blood flow, etc.

IEM data processing related to acceleration, includes, for example,direct acceleration, which includes total activity and derivedacceleration, which further includes activity type.

IEM data processing related to optical includes, for example,hematocrit, 02 saturation, pulse oximetry, etc.

IEM data processing related to temperature includes, for example, bodytemperature, heat flux, etc.

IEM data processing related to sound includes, for example, heartsounds, valvular events, etc.

IEM data processing related to biochemical/biological includes, forexample, lactose, glucose, antibody, biomarker, bacterial, osmolarity,etc.

IEM data processing related to derived data include, for example, sleep,total energy, etc.

2.1.1.6 Storage Repositories

Ingestible event marker data also includes data related to storagerepositories 310, i.e., databases and I or other storage implementationsthat temporarily and I or permanently retain, store, etc., data relatedto IEM data, including data to be combined or aggregated with ingestibleevent marker data.

Storage may be in any form or format, as is known or will be known inthe future. In various aspects, the storage repositories 310 may beindependently embodied and I or may be partially or wholly integratedwith computer-related system(s). The storage repositories 310, forexample, may interoperate or otherwise be associated with variouscomputer systems, software, hardware, communication components, etc. Forexample, the storage repositories 310, may be part of a medical officecomputer system and may contain IEM data 200 related to a particular'spatient's medication regimen. At various times, e.g., scheduled or adhoc, various IEM data 200 embodied as medical data may be communicatedto/from the storage repositories 310 and/or from/to variouspoints/components.

In another illustration, methods, systems and compositions that allowfor treating a patient according to a patient customized therapeuticregimen are described in PCT/US2007/1068, filed May 2, 2007, whichinclude obtaining dosage administration information from a patient andusing the same to tailor a therapeutic regimen for the patient, as wellas preparing and forwarding to the patient physical pharmaceuticaldosages based on the customized therapeutic regimen. The dosageadministration information from the patient may be stored, for example,on the database 306. The IEM data 200 containing information about theingestion time of a particular medication can be combined with thedosage administration information to customize the therapeutic regimen.

2.1.1.7 Other IEM Data Sources

In various aspects, various other IEM data sources 312, such as amultisensory lead 312 a are/can be included. Further, it is noted thatdata and/or IEM data 200 from multiple sources can be aggregated,integrated, refined, etc. via a variety of methods. To illustrate, IEMdata 200 such as ingestion data related to ingestion of a medication aregenerated from an IEM data source device 300 such as the IEM system. Theingestion data are wirelessly transmitted to an IEM receiver.

Concurrently or in an alternative time period, physiologic data such ascardiac parameters are generated by a health device 300 c such as thesystem for monitoring and treating hemodynamic parameters, supra, isgenerated and wirelessly transmitted to the IEM data receiver 300 b. TheIEM data 200 and the cardiac physiologic data are aggregated for onwardcommunication to an IEM data system such as an auto refill system.

To illustrate, cardiac data is derived via various methods and systems.One example is continuous field tomography, e.g., electrical tomography(ET). One continuous field tomography method is described in the U.S.Patent Application Ser. No. 60/797,403, filed May 2, 2006. The cardiacdata includes cardiac-related parameters, as well as clinical data forclinical applications. Using ET, various cardiac parameters aremeasured, such as stroke volume, ejection fraction, dP/dt(max), strainrate(max), peak systolic mitral annular velocity, end systolic volume,end diastolic volume, and QRS length, etc. The cardiac measurements maybe used to derive or infer various performance and wellnessdiagnostics/inferences. For example, an ejection fraction parameter maybe used as a basis to predict ventricular synchrony performance.

The metrics generated from the continuous field tomography include, forexample, velocity, acceleration, and displacement.

The clinical data derived from the metrics include, for example, leftventricle stiffness as well as ET proxies for other physiologicparameters such as ejection fraction (EF) and dP/dt.

In various aspects, the clinical data may be combined with the IEM datato provide additional information. The information may be useful, forexample, in various diagnostic and analytical pursuits. Comprehensivepatient-related data displays having clinical data and IEM data aredescribed in the U.S. Patent Application Ser. No. 61/076,577, filed Jun.27, 2008, wherein various ET physiologic parameters and derivations suchas EF and ventricle stiffness are displayed together with IEM data suchas medication ingestion time. From such a display, the efficacy of themedication therapy may be gauged.

2.2 Hub

The hub 202 includes any hardware device, software, and/orcommunications component(s), as well as systems, subsystems, andcombinations of the same which generally function to communicate the IEMdata 200, including receiving, storing, manipulating, displaying,processing, and/or transmitting the IEM data 200.

In various aspects, the hub 202 receives, generates, communicates,and/or transmits, the IEM data 200, alone or in combination with otherdata, i.e., non-lEM data from various sources. Non-lEM data includesnon-lEM physiologic data. Examples of non-lEM data include heart rate,heart rate variability, respiration, physical activity level, wakepatterns, temperature, etc.

Communication of the IEM data 200 to and from the hub 202 includes anytransmission means or carriers, and combinations thereof, includingwireless, wired, RF, conductive, etc. as is known in the art or as maybecome available in the future.

FIG. 4 illustrates the hub 202 associated with the IEM data framework102 of FIG. 2, according to one embodiment. The hub 202 comprisesvarious categories of devices, e.g., personal communication devices,base stations, and mobile telephones.

Personal communication devices include, for example, devices havingcommunication and computer functionality and typically intended forindividual use, e.g., mobile computers, sometimes referred to as“handheld devices”.

Base stations comprise any device or appliance capable of receiving datasuch as IEM data. Examples include computers, such as desktop computersand laptop computers, and intelligent devices/appliances.

Intelligent devices/appliances include consumer and home devices andappliances that are capable of receipt of data such as IEM data.Intelligent devices/appliances may also perform other data-relatedfunctions, e.g., transmit, display, store, and/or process data. Examplesof intelligent devices/appliances include devices and appliances havingrefrigerators, weight scales, toilets, televisions, door frame activitymonitors, bedside monitors, bed scales. Such devices and appliances mayinclude additional functionality such as sensing or monitoring variousphysiologic parameters, e.g., weight, heart rate, etc.

Mobile telephones include telephonic communication devices associatedwith various mobile technologies, e.g., cellular networks.

In one aspect, the hub 202 includes an IEM data receiver embodied, forexample, as a receiver such as a patch receiver 400; a personalcommunication devices such as a handheld device 402; a base station 404;and a mobile telephone 406.

The patch receiver 400 includes, for example, devices capable of atleast receiving data, signals, etc. Patch receivers 400 may beattachable, e.g., permanently or removably attachable externally to ahuman body or a non-human body. For example, the patch receiver 400 mayinclude a receiver and an adhesive layer to provide for attachment toand removal from a region of skin. Alternatively, the patch receiver 400may be implantable or semi-implantable, e.g., subcutaneous implantation.One such removably attachable patch receiver 400 is the personal signalreceiver of the IEM system described in PCT/US2008/52845, supra.

The handheld device 402, also referred to as a “mobile computer”,includes, for example, computing devices having computer-relatedfunctionality, e.g., typically having a display screen with touch inputfunctionality, a miniature keyboard, etc. Types of handheld devicesinclude, for example, a personal digital assistant (PDA) having theinput and output combined into a touch-screen interface; and enterprisedigital assistants offering integrated data capture devices like barcode, radio frequency identification (RFID), and smart card readers,etc.

In various aspects, the handheld device 402 includes software, e.g., asoftware agent/application, associated with the IEM data 200. In variousembodiments of the handheld device 402, the software is preconfigured,i.e., configurable by the manufacturer/retailer; configurable by theconsumer, i.e., downloadable from a website; or a combination of thesame.

One example of software is an auto refill application related to orintegrated with an auto refill system to facilitate automatedprescription refill functions.

The base station 404 includes systems, subsystems, devices, and/orcomponents that receive, transmit, and I or relay the IEM data 200. Invarious aspects, the base station communicably interoperates with areceiver such as the patch receiver 400 and a communications networksuch as the Internet. Examples of base stations 404 are computers, e.g.,servers, personal computers, desktop computers, laptop computers,intelligent devices/appliances, etc., as heretofore discussed.

In various aspects, the base station 404 may be embodied as anintegrated unit or as distributed components, e.g., a desktop computerand a mobile telephone in communication with one another and incommunication with a patch receiver and the Internet.

In some aspects, the base station 404 includes the functionality towirelessly receive and I or wirelessly transmit data, e.g., IEM data 200received from and transmitted to the patch receiver 400 and theInternet.

Further, in various aspects, the base station 404 may incorporate and/orbe associated with, e.g., communicate with, various devices. Suchdevices may generate, receive, and I or communicate data, e.g., IEM data200. The devices include, for example, clock radios, intelligent pilldispensers, pill managers, e.g., devices capable of receiving varioussubstances and producing a combined substance, dose(s) of substances,etc., pharmaceutical compounding devices, “intelligent” devices such asscales, blood pressure measurement devices, exercise equipment, e.g.,tread mills. Further examples include body weight sensors, motionsensors, position sensors, e.g., bed sensors, chair sensors, portals indoorways, refrigerator and food devices, bathroom facilities devices,etc.

The mobile telephone 406 includes, for example, devices such as ashort-range, portable electronic device used for mobile voice or datacommunication over a network of specialized cell site base stations. Themobile telephone 406 is sometimes known as or referred to as “mobile”,“wireless”, “cellular phone”, “cell phone”, or “hand phone (HP)”.

In addition to the standard voice function of a telephone, variousembodiments of mobile telephones may support many additional servicesand accessories such as short message service (SMS) for text messaging,email, packet switching for access to the Internet, java gaming,Bluetooth (short range data/voice communications), infrared, camera withvideo recorder, and MMS for sending and receiving photos and video. Someembodiments of mobile telephones connect to a cellular network of basestations (cell sites), which is, in turn, interconnected to the publicswitched telephone network (PSTN) or satellite communications in thecase of satellite phones. Various embodiments of mobile telephones canconnect to the Internet, at least a portion of which can be navigatedusing the mobile telephones.

In various aspects, the mobile telephone 406 includes software, e.g., asoftware agent/application, associated with the IEM data 200. Oneexample is an auto refill application related to or integrated with anauto refill system to facilitate automated prescription refillfunctions. In various embodiments of the mobile telephone 406, thesoftware is preconfigured, i.e., configurable by themanufacturer/retailer; configurable by the consumer, i.e., downloadablefrom a website; or a combination of the same.

Further, various embodiments of the hub ensure privacy requirements viapredetermined methods, e.g., an IEM data source device 300 ingested byan individual transmits sensitive IEM data 200 via body tissues to anIEM data receiver 302 embodied in a patch receiver 400 removablyattached to the individual's body. Signals associated with the sensitiveIEM data 200 remain undetectable beyond the individual's body. Oncereceived by the patch receiver 400, various computing components of thepatch receiver 400 cleanse and I or encrypt the IEM data 200 for onwardsecure transmission. In this manner, breaches of sensitive datatransmissions and I or unauthorized access to the sensitive data areavoided.

Further, various aspects of the hub include combinations of devices. Onesuch combination is an IEM data receiver 300 b such as the patchreceiver 400 in communication with the handheld device 402 or the mobiletelephone 406. Thus, for example, the patch receiver 400 wirelesslytransmits IEM data 200 to the mobile telephone 406 having a receiver anda software agent available thereon. The receiver of the mobile telephone406 receives the IEM data 200. A software agent, e.g., an application,processes the ingested reported data 200 and displays variousinformation related to the IEM data 200 via, for example, a customizedgraphical user interface (GUI). In some aspects, the software agentgenerates displays with a predetermined “look and feel”, i.e.,recognizable to a user as belonging to a predetermined group of softwareprograms, GUls, source devices, communities, etc.

To illustrate the foregoing, the IEM data 200 may include data about aningested medication. Once received by the mobile telephone 406, thesoftware agent may compare the data about the medication to apredetermined medication regimen. Upon verification that the propermedication has been ingested at the proper time, the software disablesan audible alarm scheduled to alert the individual to take the (alreadyingested) medication, thus averting an unnecessary reminder and removingthe annoyance associated therewith. The software agent, via the GUI,displays a standard message to the individual notifying of themedication ingested and the time of the next dosage.

Additionally, the software agent may include functionality to generateor facilitate a financial transaction. In one example, upon occurrenceof a certain event, such as verification that the proper medication hasbeen ingested at the proper time, the software agent generates apredetermined charge for the ingested medication, the verificationservice, or both. The charge is transmitted to a financial system, e.g.,the patient's cell phone transmits the charge via an IEM data system toa computer system associated with the patient's financial institutionwhere the charge is automatically applied against a financial account ofthe patient.

In various other aspects, the transaction model may be based on variousparameters. In one example, a transaction is associated with a timebased model wherein use of a product or service is charged according tothe length of time the product or service is used. In another example, atransaction is associated with a measured value delivery, wherein thevalue of the product or service is metered, measured, or otherwisevalued and charged according to the ascertained value at predeterminedtime intervals. In still another example, a transaction is associatedwith therapy delivery, i.e., delivery of a therapeutic substance, event,service, etc. Examples of therapeutic substances include medication.Examples of therapeutic events include cardiac defibrillation acts andcardiac resynchronization acts. Examples of therapeutic services includeadministration of therapeutics, therapeutic consultations, etc.

2.3 IEM Data Systems

The IEM data systems 204 include any hardware component, softwarecomponent, and/or communications component, as well as networks,systems, and subsystems of the same, which generally function to providea service, function, activity, etc. related to the IEM data 200. The IEMdata systems, for example, collect, manipulate, calculate, transmit,receive, store, and/or otherwise communicate at least a portion of theIEM data.

Each IEM data system is built around a predefined business function orservice and is enabled via the IEM data framework. One or more IEM datasystems may be integrated, interoperate, intercommunicate or otherwiseshare or further the collection, management, distribution/dissemination,billing and/or other activities related to IEM data.

Further, one or more IEM data systems may be associated with one or morecommercial systems. For example, one or more IEM data systems may beintegrated with, interoperate with, and/or intercommunicate with one ormore commercial systems. One or more IEM data systems may otherwiseshare or further the IEM data related activities with one or morecommercial systems.

The IEM data systems 204 include at least one component, e.g., hardwaredevice, software, and I or communications component, which generallyfunction to provide a service or activity related to the IEM data 200,e.g., a computer to receive IEM data 200 from the hub 202 and displaythe IEM data 200 in conjunction with other information.

Examples of components include a computer, a receiver, a transmitter, anapplication, a software module, a data storage medium, a processor, amemory component, a personal communication device, software, acommunication link, and a handheld device. It is noted that two or moreIEM data systems 204 can cooperatively or independently use one or moreof the same components. For example, an auto refill system and anapproval system can each access a data storage medium having IEM datarelated to patients and prescriptions and can each utilize the IEM datafor predetermined purpose(s).

FIG. 5 illustrates exemplary IEM data systems 204 associated with theIEM data framework of FIG. 2, according to one embodiment. The exemplaryIEM data systems 204 include, for example, feedback loop systems 204 a,decision support systems 204 b, auto refill systems 204 c, patient tools204 d, behavioral medicine systems 204 e, incentive systems 204 f,personalized commercial products/services 204 g, auto billing systems204 h, tracking systems 204 i, interdiction systems 204 j, subscriptionsystems 204 k, IEM data collections 2041, approval systems 204 m,forecasting systems 204 n, financial systems 2040, an IEM data phonesystem 204 p, and social networks 204 q.

2.3.1 Feedback Loop Systems

Feedback loop systems aggregate various sources of data, e.g., IEM data,analyze the aggregated data, and/or provide feedback information tomultiple profile recipients based on the aggregation/analysis.

FIG. 6 illustrates an exemplary IEM data framework 102 including afeedback loop system 204 a, according to one embodiment. The feedbackloop system 204 a includes, for example, server 500 having application502 and database 504. The IEM data framework 102 further includes IEMdata 200 and the hub, embodied here as the mobile telephone 406. Invarious aspects, the feedback loop system 204 a may interoperate, or beotherwise associated with, one or more IEM data systems 204 and/or oneor more commercial systems 106.

In one scenario, a patient 506 ingests medication having an ingestibledevice integrated therein. The ingestible device generates IEM data 200in the form of medication identification and time of ingestioninformation. The ingestible device transmits the information to areceiver. The receiver, in turn, communicates the information to the hub202 embodied as a mobile telephone 406 associated with the patient 506.

A software agent resident on the mobile telephone 406 aggregates thereceived medication identification and time of ingestion informationwith the blood pressure measurement information and forwards theaggregated data to the feedback loop system 204 a. The feedback loopsystem 204 a, having server 500, software 502, and database 504,receives the aggregated data from the mobile telephone 406 and, via thesoftware 502, compares the aggregated data to patient information in thedatabase 504 to determine if the patient 506 took the most recent doseof medication in a timely manner, if the patient 506 has consistentlytaken the medication in a timely manner, and if the blood pressuremeasurement coincides with an acceptable range of blood pressuremeasurements.

Based on an analysis of the data, the feedback loop system 204 agenerates additional IEM data 200 in the form of a decision on patientadherence and a decision on treatment efficacy. The IEM data 200decisions are stored in database 504 for future reference and forwardedto a commercial system such as a healthcare system 106 a associated witha medical center computer system and having patient data such asphysician's medication instructions, etc.

The healthcare system 106 a facilitates automatic processing andfeedback, enables accessibility to the IEM data 200, e.g., by ahealthcare provider, enables data input, e.g., healthcare instructionsby the healthcare provider, etc.

For example, the healthcare system 106 a compares the decision datareceived from the feedback loop system 106 a with stored healthcareproviders instructions, e.g., medication regimen adherence issatisfactory and no action is needed at this time; medication regimenadherence is not satisfactory and action is needed at this time;medication regimen is satisfactory but action is needed at this time,e.g., titration is needed, etc., and generates the comparison resultdata for review by the healthcare provider.

The healthcare provider utilizes the information to advantageouslyadjust patient treatment parameters, e.g., prescription and dosagerequirements. The healthcare provider inputs data based on thecomparison results, e.g., the adjusted treatment parameters. The inputdata are processed by the healthcare system 106 a and forwarded to thefeedback loop system 204 a. The feedback loop system 204 a receives thefeedback loop data, reconciles the feedback loop data with the patientinformation resident in the database 504, and forwards the notificationto the mobile telephone 406 of the patient 506.

In various aspects, the feedback loop system 204 a and/or the healthcaresystem 106 a interoperate, e.g., communicate with at least one other IEMdata system 204 and/or commercial system 106.

To continue the foregoing illustration, in addition to forwarding theadjusted medication regimen instructions to the patient's mobiletelephone 406, either the feedback loop system 204 a or the healthcaresystem 106 a forwards the adjusted medication regimen in the form of aprescription to a commercial system such as a pharmacy system 106 b forrefill. The pharmacy system 106 b fills the prescription andcommunicates a message to the feedback loop system 204 a notifying ofthe same. The feedback loop system 204 a updates the patient's data indatabase 504 to reflect the new prescription and fulfillment of theprescription, and communicates the notification to the patient's mobiletelephone 406.

2.3.2 Decision Support Systems

Decision support systems, e.g., personal wellness systems, may generate,store, provide data, e.g., IEM data, which may be used to inform andsupport decisions, e.g., stakeholders' decisions. In one example,multiple instances of individualized ingestible event marker data andphysiologic data are gathered and combined into anonymized patientpopulation data. Pharmaceutical research and development groups,universities, etc., utilize the data for various purposes, e.g.,information to formulate new product lines, adjust existing therapies,etc. The data may be accessed, for example, by subscription topopulation data feeds, access to the database, etc.

FIG. 7 illustrates an exemplary IEM data framework 102 having a decisionsupport system 204 b, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub 202, shown hereembodied as the mobile telephone 406. In various aspects, the feedbackloop system 204 a may interoperate, or be otherwise associated with, oneor more IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, IEM data, e.g., IEM data 200 a and IEM data 200 b,related to multiple individuals, e.g., patient 506 a and patient 506 b,respectively, are communicated via the hubs, e.g., mobile telephone 406a and mobile telephone 406 b, respectively, to the decision supportsystem 204 b comprising, for example, server 500, software 502, anddatabase 504. The IEM data 200 a and 200 b may be encrypted. Thedecision support system 204 b processes and stores the received data.For example, software 502 anonymizes the patient data, i.e., removes allaspects of the data tending to identify an individual and removes,according to a predetermined scheme, all aspects of the data designatedas private, sensitive, confidential in nature, etc. The software 502 mayprovide various other functions such as integrating the anonymizedpatient data with existing patient population data in the database 504.

The integrated data in database 504 may be accessed by, delivered to, orotherwise utilized by multiple systems and parties. Such systems includefor example, commercial systems 104 such as pharmaceutic systems 106 cand university systems 106 d. Parties associated with the pharmaceuticsystems 106 c may utilize the patient population data, for example, forstatistical analysis and projective capabilities such as determining theefficacy, cost efficiency, profit, etc. of a particular medication andprojecting from the determination new product line concepts/therapies,etc. Parties associated with universities may utilize the patientpopulation data to research symptomatology, analyze medication risks,etc.

In various aspects, the decision support system 204 b, IEM datasystem(s), and I or commercial system(s) interoperate, e.g.,communicate, therebetween.

To continue the foregoing illustration, in addition to the provision ofdecision support data such as patient population data, the decisionsupport system 204 b communicates patient population data to thefeedback loop system 204 a. The feedback loop system 204 a communicatesthe patient population data to mobile telephone 406 a of patient 506 a.

In one scenario, the decision data derived from a patient populationsuch as medication efficacy may be correlated with an individual'smedication therapy, and communicated via marketing system specificallytargeted for that individual.

2.3.3 Auto Refill Systems

Auto refill systems automatically fill or refill prescriptions. In oneexample, IEM data identifying an ingested medication are gathered andreconciled with current prescription information to identify depletedprescription supplies. If the supply is depleted, a refill order isautomatically triggered to the appropriate pharmacy. The pharmacyautomatically refills the order, generates a bill, and charges theappropriate account, e.g., via a real time, online financialtransaction.

FIG. 8 illustrates an exemplary IEM data framework 102 having an autorefill system 204 c, according to one embodiment. The IEM data framework102 further includes IEM data 200 and the hub 202, shown here embodiedas the base station 404. In various aspects, the auto refill system 204c may interoperate, or be otherwise associated with, one or more IEMdata systems 204 and I or one or more commercial systems 106.

In one scenario, the patient 506 ingests prescription medication inconjunction with an ingestible device. The ingestible device identifiesthe medication type and dosage, and transmits the IEM data 200 via, forexample, conductive transmission to the patch receiver 400, which may beremovably attached to the patient 506. The patch receiver 400 transmitsthe IEM data 200 to base station 404. The base station 400 forwards theIEM data 200 to the auto refill system 204 c. The software 502 of theauto refill system 204 c compares the medication type and dosage of theIEM data 200 against prescription information stored in the database504. The prescription information, for example, may include the numberof tablets in the prescription at time of fill, the dosage instructions,and a running total of the ingested tablets as per previously receivedinformation. If the comparison indicates depletion of the prescriptionmedication, database 504 is checked for the number of remaining refills.If refills are remaining, any sensitive data of the IEM data 200 arecleansed, i.e., removed, and a prescription refill request withpertinent information is compiled and transmitted according topredetermined security protocol and via predetermined channel(s) to acommercial system 106 such as the pharmacy system 106 b. Upon receipt bythe pharmacy system 106 b, the refill request is parsed and verified,and the prescription is refilled.

Payment for refill can be effected, for example, via a real-time, onlinetransaction between the pharmacy system 106 b and an IEM data system 204and I or commercial system, e.g., financial transaction system 106 e.The financial transaction system 106 e, for example, may receive thefinancial transaction, e.g., prescription refill charge, via apredetermination communication channel. The financial transaction system106 e verifies the patient account information and completes thetransaction, notifying the pharmacy system 106 b.

Notification of status of refill and payment for refill can be providedvia predetermined communication channel(s) to the base station 300,e.g., an email for display on the laptop computer, a text message to thepatient's mobile telephone, etc.

2.3.4 Patient Tools

Patient tools include any data, information, software, websites, etc.that provide information or assist a particular patient focus, e.g.,tracking tools to assist a patient in cardiac health management, patientpersonalization of their own data, etc. Various users may be associatedwith the patient tools. Examples include various users within a patientcommunity, e.g., patients, family caregivers, and professionalcaregivers such as physicians.

FIG. 9 illustrates an exemplary IEM data framework 102 having a patienttools 204 d, according to one embodiment. The IEM data framework 102further includes IEM data 200 a-c and the hubs, shown here embodied asthe base station 404, the mobile telephone 406, and the handheld device402. In various aspects, the patient tools 204 d may interoperate, or beotherwise associated with, one or more IEM data systems 204 and/or oneor more commercial systems 106.

In one scenario, multiple parties such as patients 506 a-c access thepatient tools 204 d, which may be embodied as the server 500 having thesoftware 502 and the database 504 having IEM data 200 in the form of atleast patient tools. Patients 506 a-c may access the patient tools 204d, for example, via the base station 404, the mobile telephone 406, andthe handheld device 402, respectively.

Patient 506 b may search the database 504 for patient tools related tomental illness management. The patient tools, for example, may beprovided in the form of downloadable data/applications to assist intracking, monitoring, diagnosing, and notifying a patient of a relevanthealth issue, e.g., medication dosage schedule, etc. Patient 506 b maydownload the application onto, for example, the mobile telephone 406.Patient 506 b may further communicate via, for example, the mobiletelephone 406 with at least one commercial system such as the healthcaresystem 106 a, which may provide further medical data, instruction, etc.,relevant to the patient 506 b's mental illness management pursuit.

In various aspects the patient tools 204 d may be configured for andutilized by for various parties besides the patient, e.g., a patientcommunity, family caregivers, and professional caregivers.

2.3.5 Behavioral Medicine Systems

Behavioral medicine systems may collect, track, and analyzebehavior-related data to identify causal failure points in treatment andto predict corrective action by prescribing specific behaviormodifications. In various aspects, the behavioral medicine systems mayassist patients via questionnaires and patient profile assessment onsymptomatologic or therapeutic subjects, e.g., in various decisionprocesses by display a menu-guided series of questions and receivinganswer(s) from the patient.

FIG. 10 illustrates an exemplary IEM data framework 102 having abehavioral medicine system 204 e, according to one embodiment. The IEMdata framework 102 further includes IEM data 200 and the hub, shown hereembodied as the base station 404 and the mobile telephone 406. Invarious aspects, the behavioral medicine system 204 e may interoperate,or be otherwise associated with, one or more IEM data systems 204 and/orone or more commercial systems 106.

In one scenario, the behavioral medicine system 204 e, e.g., a softwareagent, may be located in whole or in part on a patient-related devicesuch as the mobile telephone 406. The software agent may assist thepatient in various endeavors, e.g., diet choices, smoking cessation,etc. The assistance may be provided, by example, by generating fordisplay on the mobile telephone 406 question sets related to diet andsmoking cessation. The patient may answer the questions, e.g., selectfrom various answer options. Based on the patient's answers to thequestions, the software agent may categorize the patient according topredetermined categories. The software agent may provide language andmenu choices based on the patient categorization.

In another scenario, patient behavior is tracked with respect to variousIEM data, e.g., patient parameters, sometimes referred to herein as“sentinels for wellness”. Examples of sentinels for wellness includemedication therapy adherence, weight, blood pressure, etc. The sentinelsfor wellness may be derived, for example, from various health devices300 c such as intelligent scales, cardiac-related devices, etc.

To illustrate, patient 506 ingests medication according to physicianinstructions. The IEM data 200 in the form of ingestion informationidentifying the ingested medication and the time of ingestion arecaptured via an ingestion device and communicated to the patient'smobile telephone 406. Also captured via health device(s) 300 c at thetime of medication ingestion are the patient's blood pressure andweight. The timing of the foregoing data captures may be synchronizedvia, for example, software utilizing a reminder system to alert thepatient to take the medication at a particular time. Upon receiving theingestion information, e.g., confirmation of ingestion, the softwareassociated with the mobile telephone 406 communicably triggers healthdevice(s) 300 c to determine blood pressure and weight, and forwardssuch data to the mobile telephone 406 for aggregation with the IEM data200 in the form of the ingestion information.

The aggregated data may be forwarded to behavioral medicine system 204e, which may be configured, for example, as the mobile telephone andsoftware 406, the server 500 including the software 502 and the database504, and/or other configurations. Upon receipt of the aggregated data,various processing may take place.

One example of processing is analysis of the IEM data 200 to determinedegree of patient adherence to medication regimen, i.e., determine ifthe patient ingested the prescribed medication in the right dosage atthe prescribed time interval(s).

Another example of processing is analysis of the IEM data 200 todetermine if the blood pressure measurement is in line with physicianexpectations. Thus, the notification of patient adherence to themedication regimen and the blood pressure measurement may becommunicated to a physician system 106 f for review by the patient'sphysician. The physician, in turn, may update the IEM data 200, e.g.,determine an adjustment in the medication regimen is needed andcommunicate, via the behavioral medicine system, the updated medicationregimen to the patient's mobile telephone 406 and to the pharmacy system106 b for filling the updated prescription.

In cases of a nonadherence determination, the physician may alert thepatient, via the behavioral medicine system 204 e, to make anappointment for a physical review. In various aspects, the behavioralmedicine system 204 e may generate and/or forward a reminder to the hub,e.g., mobile telephone 406 of the patient 506. The reminder, forexample, may include the dosing schedule, a reminder for the upcomingdose, instructions to follow in case of a missed dose, etc.

In cases of underdosage/overdosage, the behavioral medicine system 204 emay interoperate with an alert system, e.g., the IEM data phone system,infra, and compare current dosage information to predeterminedthresholds to determine if a critical status dosing event exists, e.g.,the patient is critically underdosed or critically overdosed. If such adetermination is made, the appropriate system may generate an alert toappropriate parties, e.g., generate a 911 emergency call for medicalassistance, generate an emergency alert to the physician system 106 f,and generate an alert to a family caregiver system 106 g, e.g., a familymember's mobile telephone.

In still another scenario, analysis of the patient's communicationpatterns/habits is performed to determine patient parameters, indicatedactions, etc. To illustrate, an application such as software 502resident on the mobile telephone 406 tracks the patient's phone usage todetermine communication patterns. For example, the family caregivers,physician, etc., may selectively configure tracking parameters of theapplication to determine various patient communication thresholds,patterns, etc. The software monitors communication from/to the selecteddevice, e.g., the patient's mobile telephone 406. In various aspects,the application mines mobile telephone records of the associated carrierto determine calling and called parties, heavy volume call time, no calltimes, etc. and builds a profile against the same. The applicationmonitors use of the mobile telephone 406 and identifies significant,e.g., user selected, deviations from the profile. Upon identification ofa deviation, the application initiates predetermined actions, e.g.,communicates an alert to the physician and I or family caregiver via thehealthcare system 106 a, the physician system 106 f, and I or the familycaregiver system 106 g.

Another example of processing is analysis of the IEM data 200 togetherwith data from another source 314, e.g., aggregated data. The aggregateddata may be collected from various sources, aggregated at various and/ormultiple points, and I or communicated via various channels to/fromvarious devices.

To illustrate, cardiac data is derived via electrical tomography, asheretofore discussed. The cardiac data is communicated directly orindirectly, e.g., by the patch receiver 400, to a software applicationon the hub, e.g., the mobile telephone 406. The software application onthe mobile telephone 406 aggregates the cardiac data with the IEM data,e.g., pill ingestion-related data, and displays the various data via agraphical user interface (GUI).

Subsequent to enrollment, the behavioral medicine system ascertains thatthe patient has neglected to take the medication at the appropriatetimes. Reminder alerts for upcoming medication dosing time(s) are sentto the patient via the mobile telephone. Upon receiving the alerts, thepatient timely ingests the medication, resulting in a change in thesentinels for wellness.

2.3.6 Incentive Systems

Incentive systems provide incentives and rebates through variousprograms. The incentives and rebates are based on, or otherwiseassociated with, the IEM data. The IEM data may be analyzed via, forexample, an IEM data system 204 to determine if certaincriteria/thresholds/goals are evident. Based on the determination,incentives tied to or associated with the criteria/threshold/goals maybe generated.

FIG. 11 illustrates an exemplary IEM data framework 102 having anincentive system 204 f, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as the mobile telephone 406. In various aspects, the incentivesystem 204 f may interoperate, or be otherwise associated with, one ormore IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, patient adherence is tracked with respect to variouspatient parameters, e.g., medication therapy and adherence. Incentivesmay be awarded accordingly. For example, patient 506 ingests medicationaccording to physician instructions. The IEM data 200 in the form ofingestion information identifying the ingested medication and the timeof ingestion are captured via an ingestion device and communicated tothe patient's mobile telephone 406, and to the behavioral medicinesystem 204 e. The behavioral medicine system 204 e verifies patient 506adherence to the prescribed medication regimen, and sends verificationto the incentive system 204 f. The incentive system 204 f, via thesoftware 502 and the database 504, determines the price paid for themedication, and issues a rebate or credit against the cost. For example,the rebate may be issued and a financial transaction in the amount ofthe rebate posted to the patient's financial account via the financialtransaction system 106 e.

In another example, the rebate may be communicated and applied to anaccount associated with the patient via the pharmacy system 106 b with,for example, a credit against the next refill for the patient'sprescription medication.

In another example, the patient's blood pressure and weight may becaptured via health device(s) 300 c at time of medication ingestion. Thetiming of the foregoing data captures may be synchronized via softwareutilizing a reminder system to alert the patient to take the medicationat a particular time. Upon receiving the ingestion information, e.g.,confirmation of ingestion, the software associated with the mobiletelephone 406 may communicably trigger health device(s) 300 c todetermine blood pressure and weight, and forward such data to the mobiletelephone 406 for aggregation with the IEM data 200 in the form of theingestion information. The aggregated data may be communicated to theincentive system 204 f where the software 502 and/or database 504 may beutilized to determine if the patient's weight and blood pressure meetacceptable predetermined thresholds. If, for example, the weight exceedsan acceptable threshold, the incentive system 204 f may generate anincentive in the form of a discount membership offering at a localhealth club, etc. The offering may be constructed using various dataparameters and demographics, e.g., geographical location of the patient,amount of weight to be lost, health assessment scoring based onindividualized patient health parameters, lists of participating healthclubs, etc.

The incentive may be communicated to the patient 506 via, for example,the patient's mobile telephone 506.

2.3.7 Personalized Commercial Products/Services

Personalized commercial products/services provide individualizedproducts and services predicated on or related to IEM data.

FIG. 12 illustrates an exemplary IEM data framework 102 having apersonalized commercial products/services system 204 g, according to oneembodiment. The IEM data framework 102 further includes IEM data 200 andthe hub 202. In various aspects, the commercial products/services system204 g may be embodied as, for example, an IEM data device, e.g., a patchreceiver. In various aspects, the commercial products/services system204 g may interoperate, or be otherwise associated with, one or more IEMdata systems 204 and/or one or more commercial systems 106.

In one scenario, commercial products/services system 204 g includeconsumer-friendly receivers, such as patch receivers. The receiverscomprise various accessories and incorporate various designs. Forexample, children's patch receivers may comprise cartoon characterappliques. Youths' patch receivers may comprise tattoo-like designaspects. Further examples include IEM data receivers embodiedas/integrated into accessories, e.g., earrings, naval rings, and othermeans of adornment, etc.

Commercial products/services system 204 g further comprise branded or“community” associated products and services.

2.3.8 Auto Billing Systems

Auto billing systems receive, process, and I or facilitate payment via afinancial account. Auto billing applications associated with the autobilling system and I or with financial institution systems seamlesslyinteroperate to generate a bill, verify accountholder information,charge an account, etc. Statements are updated to reflect paymentinformation. Similar applications may be applied for prescriptions,consumer products, information provision via personal devices, etc.

FIG. 13 illustrates an exemplary IEM data framework 102 having an autobilling system 204 h, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as the handheld device 402. In various aspects, the autobilling system 204 h may interoperate, or be otherwise associated with,one or more IEM data systems 204 and/or one or more commercial systems106.

In one scenario, various parties such as patient 506, physicians,pharmaceutical companies, etc., subscribe to information feeds/patientpopulation data of IEM data 200 to further business goals, manage healthcare, etc. The parties may receive the information feeds/accesspopulation data, etc. via a variety of devices. For example, patient 506may receive an information feed via hub 202 embodied as the handhelddevice 402, which, via a software agent, may generate a financialtransaction in the form of an invoice for the information feed displayedfor the patient 506. Payment may be effected via automated methods.

In a patient selection method, for example, the patient selects variouspayment options via the software agent resident on the handheld device402. A payment transaction is generated and communicated to thefinancial transaction system 106 e. The financial transaction system 106e automatically charges an account associated with the patient 506.Confirmation of the payment together with digital, e.g., electronic,copies of the invoice are provided to the software agent resident on thehandheld device 402 for the patient 506 to view, etc.

In an automated method, for example, a bill and I or financialtransaction are automatically generated upon predetermined criteria. Thepredetermined criteria include, for example, delivery of informationassociated with an information feed or other source, access to a datacollection, e.g., patient population data stored in a database, etc. Thepatient selects various payment options via the software agent residenton the handheld device 402, and a payment transaction is generated andcommunicated to the financial transaction system 106 e. The financialtransaction system 106 e automatically charges an account associatedwith the patient 506. Confirmation of the payment together with digitalcopies of the invoice are provided to the software agent resident on thehandheld device 402 for the patient 506 to view, etc. For example, ahealthcare provider may access patient population data stored indecision support system 204 b via the healthcare system 106 a. Softwareof the decision support system 204 b may cooperate with the software 502and the database 504 of the auto billing system 204 h to identify theparty to be billed for the access. Upon identification, the auto billingsystem 204 h may automatically generate a bill and I or financialtransaction for the access via one or more of the aforedescribedchannels.

2.3.9 Tracking Systems

Tracking systems track and integrate product movement data. In oneexample, the life cycle of an ingestible device may be tracked frommanufacture to shipment, pharmacy inventory, delivery to patient,ingestion and expulsion.

FIG. 14 illustrates an exemplary IEM data framework 102 having atracking system 204 i, according to one embodiment. The IEM dataframework 102 further includes the IEM data 200 and the hub, shown hereembodied as a scanner 1402. In various aspects, the tracking system 204i, may interoperate, or be otherwise associated with, one or more IEMdata systems 204 and/or one or more commercial systems 106.

In one scenario, a pharmaceutical manufacturer produces an ingestibledevice 302 a such as a particular medication having an IEM system devicetherein. The IEM system device contains various IEM data 200 such asmedication identification, batch number, lot number, and manufactureridentification. The scanner 1402 may be utilized at varioustimes/locations to scan the ingestible device 302 a and capture the IEMdata 200 associated therewith. The IEM data 200 may then be stored,processed, etc., via, for example, the software 502 and the database 504of the tracking system 204 i. For example, the IEM data 200 may be readby the scanner at a shipping point and when received by a pharmacy toensure inventory control, distribution integrity, and chain of custodyfor restricted pharmaceuticals, etc.

The tracking information may be used, for example, by regulatoryagencies systems 106 i to determine regulatory adherence, etc.

2.3.10 Interdiction Systems

Interdiction systems track, reconcile, and support interdictionprograms. The interdiction programs include, for example, programsrelated to drug identification and use detection by sworn personnel,search and seizure activities, etc.

FIG. 15 illustrates an exemplary IEM data framework 102 having aninterdiction system 204 j, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and hub, shown here embodiedas a scanner 1402. In various aspects, the interdiction system 204 j mayinteroperate, or be otherwise associated with, one or more IEM datasystems 204 and/or one or more commercial systems 106.

In one scenario, a pharmaceutical manufacturer produces an ingestibledevice 302 a such as a particular medication having an IEM system devicetherein. The IEM system device contains various IEM data 200 such asmedication identification, batch number, lot number, and manufactureridentification. The scanner 1402 may be utilized at varioustimes/locations to scan the ingestible device 302 a and capture the IEMdata 200 associated therewith. The IEM data 200 may then be communicatedto, for example, the software 502 and the database 504 of theinterdiction system 204 j, where the IEM data 200 may be accessed by andcommunicated to regulatory agency systems 106 i to facilitate variousregulatory and enforcement functions, to locate missing controlledsubstances, to intercept contraband, to identify unknown substances, andto otherwise support agency and regulatory activities.

In various aspects, the IEM data 200 may be communicated to/from, forexample the interdiction system 204 j from/to the tracking system 204 i,for processing, storage, etc. For example, the IEM data 200 may be readby the scanner at a shipping point and read by a pharmacy to ensureinventory control, distribution integrity, and chain of custody forrestricted pharmaceuticals, etc. The scanned (read) IEM data 200 may bereconciled between the interdiction system 204 j and the tracking system204 i to ensure complete shipment, to track shipments through variousjurisdictions, etc. In one example, the IEM data 200 such as theidentifier data, shipment data, patient information, recipientinformation, and commercial activities are tracked and reconciled tointercept contraband and otherwise support agency and regulatoryactivities.

2.3.11 Subscription Systems

Subscription systems enable subscription to various IR information feedsand data/knowledge collections, e.g., IEM data collection system. Forexample, patients subscribe to IEM data information feeds and I or IEMdata collections, which aggregate various sources of data and fuse thedata into integrated, individualized information based on thesubscriber's requirements. The information fusion may include, forexample, personalized medication regimens and alert applications,individual social community information, music, etc. The information maybe automatically billed, for example, under a single point of chargemodel on a recurring basis. The agent may be provided as part of anembedded device, e.g., standard application on a mobile telephone, etc.

FIG. 16 illustrates an exemplary IEM data framework 102 having asubscription system 204 k, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as a mobile telephone 406. In various aspects, the subscriptionsystem 204 k may interoperate, or be otherwise associated with, one ormore IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, the patient 506 subscribes to various informationfeed(s) and/or IEM data collections, discussed hereinafter in detail.The information feed(s) include, for example, structured andnon-structured information on a variety of topics generated or deliveredfrom various sources, e.g., websites, biogs, etc. The IEM datacollections include storage repositories having IEM data. The storagerepositories may be associated, e.g., integral to or remote from, thesubscription system 204 k. For example, an IEM data collection may beresident in part or wholly in database 504 of the subscription system204 k.

In one scenario, IEM data 200 are communicated from a subscriptionsource to a subscriber, e.g., a subscriber's device. The subscriptionsource includes, for example, IEM data systems 204, e.g., the database504 of the subscription system 204 k, feedback loop system 204 a,patient tools 204 d, and decision support system 204 b; commercialsystems 106 b, e.g., online medical and business information/newsfeedsources, healthcare system 106 a; and other sources, e.g., devicesassociated with the patient 506, the hub, etc. The subscriber includes,for example, a person, group, or resource, e.g., a database, a computersystem, server, network, etc.

In various aspects, subscription services may be initiated via, forexample, a software agent resident on the hub or communication with alocal or remote system such as the healthcare system 106 a.

In various aspects, the subscriptions services may be billed and paidvia, for example, the subscription system 204 k and the financialtransaction system 106 e.

In various aspects, the subscription newsfeeds/data may be combined orintegrated into a single or multiple newsfeeds, e.g., the software 502and/or the database 504 of the subscription system 204 k may enable dataaggregation, etc.

To illustrate, the patient 506 subscribes to a healthcare newsfeed and apharmacy newsfeed, one or more having IEM data 200, via the subscriptionsystem 204 k. The patient subscribes by selecting an application, e.g.,software agent resident on the hub, illustratively embodied here as themobile telephone 406. Once the patient has selected the subscriptionoptions, the order is communicated to the subscription system 204 k,which, via the software 502 and the database 504, confirms, processes,stores, and bills the order. The subscriber's financial account may beautomatically charged, for example, by communicating invoice informationto a financial transaction system 106 e associated with the subscriber'saccount. Confirmation of the charge may be communicated from thefinancial transaction system 106 e to the subscriber via thesubscription system 204 k and/or the mobile telephone 406.

Based on the subscription parameters, the subscription system 204 kreceives the healthcare newsfeed information and the pharmacy newsfeedinformation. The software 502 of the subscription system comparessubscriber data of the patient 506 in the database 504 againstsubscriber data found in the pharmacy newsfeed, e.g., patients who areprescribed medications for cardiac therapy. Based on the comparison,software 502 separates the data of the pharmacy newsfeeds relevant tothe subscriber, combines the relevant data with the healthcare newsfeedinformation and communicates the combined newsfeed information to themobile telephone 406 for access and display.

2.3.12 IEM Data Collection System

The IEM data collection system provides/facilitates access to/storage ofthe IEM data. Examples of the IEM data include patient population dataand electronic medical records. In various aspects, IEM data collectionsmay include functionality related to the collection, management,manipulation, storage, dissemination, and billing of IEM data.

FIG. 17 illustrates an exemplary IEM data framework 102 having an IEMdata collection system 2041, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as a handheld device 402. In various aspects, the IEM datacollection system 2041, may interoperate, or be otherwise associatedwith, one or more IEM data systems 204 and/or one or more commercialsystems 106.

In one scenario, patient population data, e.g., anonymized, empiricalpatient data, is stored in one or more repositories, e.g., the database504 of the IEM data collection system 2041. The patient population datamay be received from various sources, e.g., the IEM data 200 associatedwith one or more patient 506, IEM data systems 204 such as behavioralmedicine systems 204 e, subscription systems 204 k, patient tools 204 d,etc., and commercial systems such as healthcare systems 106 a,pharmaceutic systems 106 c, university systems 106 d, etc.

In various aspects, the IEM data collection system 2041 may beconsolidated in a single physical and/or logical location, e.g., thedatabase 504 of the server 500 of the IEM data collection system 2041,or distributed across two or more systems or locations, e.g., remotelydistributed on multiple IEM data systems 204, associated with commercialsystems 106, and/or distributed between the IEM data collection system2041 and other systems/locations.

Multiprofile users may access, utilize, and/or contribute to the IEMdata collection system 2041. Multiprofile users include, for example,individuals or groups using various methods/devices for access,utilization, and/or contribution. Examples of multiprofile users includepatient 506, family members and family caregivers, professionals,academics, corporates, etc. The methods/devices include the hub devicessuch as a mobile telephone, base station, handheld device, etc., as wellas system components associated with IEM data systems and commercialsystems, e.g., laptop computer associated with a university network, adesktop computer associated with the family caregiver system 106 g, etc.

To continue the foregoing illustration, a researcher, using theuniversity system 106 d, accesses the IEM data collection system 2041via the Internet, etc. and submits queries against the patientpopulation data, extracts various data, etc.

In various aspects, the IEM data collection system 2041 includes privacyassurance, authentication, and validation mechanisms with respect tofinancial, medical, and other privacy information. For example, thesoftware 502 may authenticate users. The software 502 may cleanse/verifydata to ensure predetermined privacy thresholds are met.

2.3.13 Approval Systems

Approval systems aggregate and/or analyze various data to enable aninformed approval decision.

FIG. 18 illustrates an exemplary IEM data framework 102 having anapproval system 204 m, according to one embodiment. The IEM dataframework 102 further includes IEM data 200, the hub, shown hereembodied as a handheld device 402, and an associated intelligent pilldispenser 1802. In various aspects, the approval system 204 m, mayinteroperate, or be otherwise associated with, one or more IEM datasystems 204 and/or one or more commercial systems 106.

In one scenario, the patient 506 opens an intelligent pill dispenser1802, e.g., a pill dispenser having a microchip and communicationabilities. The patient 506 removes a pill having an IEM system from theintelligent pill dispenser 1802. The intelligent pill dispenser 1802,via its microchip, senses the removal of the pill, receives a signalfrom an IEM system that the patient 506 has ingested the pill, anddetermines the remaining quantity. If the remaining quantity is fewerthan a predetermined threshold quantity, the intelligent pill dispenser1802 communicates a refill request to the approval system 204 m. Theapproval system 204 m via, for example, the software 502 and thedatabase 504, verify information associated with the patient 506, e.g.,patient name, prescription identification, medication ingestionverification, refill timing, etc. The approval system 204 m mayinteroperate with, e.g., communicate with, various IEM data systems 204and I or commercial systems 106 to obtain/validate information. Forexample, data provided to/resident in the approval system 204 m may bereconciled with medical records of healthcare system 106, the refillrequest approved by approval system 204 m, and a refill communicated tothe pharmacy system 106 b.

2.3.14 Forecasting Systems

Forecasting systems aggregate data and I or facilitate analysis of theaggregated data/data collections to derive/generate predictiveinformation.

FIG. 19 illustrates an exemplary IEM data framework 102 having aforecasting system 204 n, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as a base station 404. In various aspects, the forecastingsystem 204 n, may interoperate, or be otherwise associated with, one ormore IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, for example, IEM data 200 are received by the basestation 404 from ingestible devices associated with patients 506 a-c.The base station 404 communicates the IEM data 200 to the IEM datacollection system 2041, which anonymizes the IEM data 200 and aggregatesthe anonymized IEM data 200 with patient population data.

The IEM data collection system 2041 communicates all or a portion of thepatient population data to the forecasting system 204 n, where thesoftware 502, e.g., one or more applications, processes the patientpopulation data to derive various statistics, conclusions, forecasts,etc., according to predetermined requirements, objectives, etc. Forexample, the software 502 processes the patient population data andcorrelates various data such as blood pressure readings over apredetermined period of time versus medication taken versus adherence tomedication regimen to determine overall efficacy of medication regimenand to forecast titrated patient dosing based on the overall efficacyfindings.

Multiple profile parties, e.g., analysts using the pharmaceutic systems106 e, agents using the regulatory agency systems 106 i, and researchersusing the university systems 106 d, access the forecasting system 204 n.The multiple profile parties utilize various tools, e.g., the software502, to run analytical and forecasting applications again the patientpopulation data and to access various forecasting data available inconnection with the forecasting system 204 n.

2.3.15 Financial Systems

Financial systems support and enable financial transactions associatedwith IEM data. In various aspects, the financial systems arecommunicably interoperable with existing automated banking systems andnetworks, etc.

FIG. 20 illustrates an exemplary IEM data framework 102 having afinancial system 2040, according to one embodiment. The IEM dataframework 102 further includes IEM data 200 and the hub, shown hereembodied as a mobile telephone 406. In various aspects, the financialsystem 2040, may interoperate, or be otherwise associated with, one ormore IEM data systems 204 and I or one or more commercial systems 106.

In one scenario, the patient 506, via the mobile telephone 406, placesan order for a product/service, e.g., a newsfeed service from thesubscription system 204 k. The subscription system 204 k, via itssoftware, interoperates with the financial system 2040. The subscriptionsystem 204 k, for example, securely communicates encrypted patientfinancial information such as account number and subscriptioninformation. The financial system 2040 authenticates the patientinformation and securely interoperates with the patient's financialinstitution, e.g., via a commercial system 106 such as the financialtransaction system 106 e to charge the patient's account and providecharge information/confirmation to the patient 506 via, for example, themobile telephone 406.

2.3.16 IEM Data Phone

The IEM data phone enables IEM data—related applications. For example,application(s) include pill regimen scheduling applications, alertreminder applications, auto refill for medication applications, patienttool applications, social networking applications, incentive trackerapplications, auto billing applications, subscription applications,approval applications, and financial transaction applications. Theapplications may be integrated with, associated with, or independent ofone another. The applications may further be manufacturer-installable onthe IEM data phone, downloadable or otherwise installable by awholesaler, retailer, user, etc. Installation may be independent orbundled with other software, products, etc. In various aspects, theapplications are user-configurable, downloadable, upgradeable, etc.

In various aspects, the IEM data phone and/or its applications may sharecommon features, e.g., a common graphical user interface (GUI);branding, i.e., a collection of images and ideas representing aneconomic producer such as concrete symbols embodied as a name, logo,slogan, design scheme, etc. The IEM data phone may also include variousconnectivity schemes, e.g., Internet and cellular; may providemultimedia capabilities; and may embody various hardware and softwareconfigurations. The IEM data phone may be embodied in a variety ofdevices, e.g., the mobile telephone 406, the handheld device 402, etc.

FIG. 21 illustrates an exemplary IEM data framework 102 having an IEMdata phone 204 p, according to one embodiment. The IEM data phone 204 pmay serve as the hub, for example. IEM data framework 102 furtherincludes IEM data 200. In various aspects, the IEM data phone 204 p, mayinteroperate, or be otherwise associated with, one or more IEM datasystems 204 and I or one or more commercial systems 106.

In one scenario, the IEM data phone 204 p includes the software 502,e.g., a portfolio of branded applications such as pill regimenscheduling, alert reminders, auto refills, patient tools, socialnetworking, incentive trackers, auto billing, subscriptions, approvals,and financial applications.

The pill regimen scheduling application may accept, reconcile, calendar,and manage contraindications and interactions of medication regimen(s).For example, the patient 506 may input information related to one ormore prescriptions, including the pharmaceutical name and dosage. Thepill regimen scheduling application may check the input informationagainst existing information stored on the IEM data phone 204 p, e.g.,in the database 504, or elsewhere, e.g., the pharmacy 106 b. The pillregimen scheduling application may provide information regardingcontraindicated medications, side effects, precautionary instructions.The pill regimen scheduling application may calendar the dosinginformation and generate alerts, e.g., reminders generated atappropriate times alerting the patient to ingest the medication. Thealerts may be audible, visual, email, text message, etc. and may beintegrated with, or independent of, alert reminder application(s).

The alert reminder application may accept or access various dataassociated with scheduling, including IEM data 200, and generate alertsat appropriate times. The alerts may be audible, visual, email, textmessage, etc. and may be integrated with or independent of alertreminder application(s). The alert application may be user-configurable,e.g., type of alert, repetition of alert, interval of repetition,receivers of alert. The alerts may be associated with various devices ofthe patient, family caregivers, friends, etc. In one example, thepatient 506 may schedule reminders to be sent to the user's device,e.g., the IEM data phone 204 p, the handheld device 402, the basestation 404, the mobile telephone 406, etc.

The alert reminder application may be integrated with otherapplications/systems. To illustrate an IEM system associated with thepatient 506 that may, for example, detect medication ingestion event(s)and communicate the IEM data 200 associated with the medicationingestion event(s) to the alert reminder application via the IEM dataphone 204 p. The alert reminder application may interoperate with thepill regimen scheduling application and perform various checks, e.g.,the ingested medication was actually prescribed for the person thatingested it; the ingested medication was ingested in the correct dosage;the ingested medication was ingested at the prescribed time interval;etc.

Predetermined criteria may be used to determine if/when the alertreminders application generates an alert, reminder, etc. To continuewith the foregoing illustration, upon a determination that the ingestedmedication was not prescribed for the person ingesting it or the wrongdosage was ingested, the alert reminder system generates alert(s) to apredetermined destination, e.g., alerts in the form of text messages tomobile telephones associated with the family caregiver system 106 g,alerts in the form of email/text messages to the healthcare system 106 aand the physician system 106 f. If the event is deemed critical, e.g.,ingestion of non-prescribed medication, overdosage, etc., the alertreminder application may generate a call from the IEM data phone 204 pto the emergency assistance system, e.g., place a 911 call. The call(prerecorded audio, text message, etc.) may contain information such asthe patient's name, the nature of the emergency, the ingestion details,physician and family caregiver information, and the physical location ofthe person ingesting the medication.

The auto refill application may facilitate automatic refill of aprescription medication via interoperation with, for example, thepharmacy system 106 b, etc.

The patient tool application may be provided on or accessible from theIEM data phone 204 p. For example, software tools for tracking dietaryand physiologic symptoms may facilitate user entry of dietary intake andsymptoms, collection of device-associated physiologic parameters such asblood pressure, heart rate, etc., correlation/analysis of the data, andfeedback based on the correlation/analysis. The patient tool applicationmay provide data, e.g., the feedback, for display on the IEM data phone204 p, the IEM data system(s) 204, and/or the commercial system(s) 106.

The social networking application may facilitate social networkingfunctionality. For example, the social networking application may retainvarious links to selected profiles of various social networks, receivedata related to the selected profiles, e.g., updates to the profiles,facilitate messaging and other communication, update the user's profile,etc., communicate with the IEM data systems(s) 204, and/or thecommercial system(s) 106, such as the patient tools/social network 204 dand the web communities 106 h.

The incentive tracker application may collect, manage, track, update,etc. incentive information. For example, the incentive trackerapplication may reconcile data associated with IEM data collectionsystems 2041 and wholesaler/retailer systems 106 j to determineincentive eligibility, e.g., a patient rebate. The incentive trackerapplication may further tally points under various reward systems,notify the patient 506 of milestones, goals, award of incentive, etc.

The auto billing application may facilitate billing for varioustransactions. The auto billing application may interoperate with variousapplications/systems, including the IEM data system(s) 204 and/or thecommercial system(s) 106, such as the billing for an auto refill via thepharmacy system, etc.

The subscription application facilitates ordering, receipt, management,etc. of various subscriptions, e.g., newsfeeds, access to various datacollections on a subscription basis, etc. The subscriptions applicationmay interoperate with various applications/systems, including the IEMdata system(s) 204 and I or the commercial system(s) 106, such as thesubscription system 204 k, the IEM data collection system 2041, etc.

The approval application aggregates and/or analyzes various sources ofdata to enable an informed approval decision. The approvals applicationmay interoperate with various applications/systems, including the IEMdata system(s) 204 and I or the commercial system(s) 106, such as theauto refill system 204 c, the subscription system 204 f, the financialsystems 2040, the pharmacy systems 106 b, the wholesaler/retailersystems 106 j, etc.

The financial application supports and enables financial transactionsassociated with IEM data 200. The financial application may interoperatewith various applications/systems, including the IEM data system(s) 204and I or the commercial system(s) 106, such as the auto refill system204 c, the incentive system 204 f, the subscription system 204 k, theapproval system 204 m, the financial systems 2040, the pharmacy system106 b, the wholesaler/retailer systems 106 j.

2.3.17 Social Network System

Social networks are a social structure made of one or more nodes, e.g.,components such as websites, accessed by individuals or organizations.The social network is typically tied by one or more specific types ofinterdependency, such as epidemiology, therapeutic regimen, healthcaremanagement, etc., and thus may attract the interest of otherwiseunrelated individuals and groups having in common an interest in theinterdependencies. Social networks may be built around variouscommunities, e.g., family caregivers, patients, medical conditions, etc.

One example of a social network is a patient information community thatprovides information related to a particular medical condition,treatments, medications, regimens, and side effects based on bothprovider and anecdotal data. The availability of such data may providebenchmark-type services, e.g., facilitate self-assessment of personalprogress and adjustment in therapies and behaviors by comparing andcontrasting an individual's progress with the particulars of othershaving the same condition, similar therapies, etc.

FIG. 22 illustrates an exemplary IEM data framework 102 having a socialnetwork system 204 q, according to one embodiment. The IEM dataframework 102 further includes IEM data 200, and the hub, shown hereembodied as the base station 404. In various aspects, the social networksystem 204 q may interoperate, or be otherwise associated with, one ormore IEM data systems 204 and/or one or more commercial systems 106.

In one scenario, patient 506 suffers from a cardiac condition. Thepatient 506 accesses the social network system 204 q, which may beembodied as the server 500 having the software 502 and the database 504having IEM data 200. Patient 506 may access the social network system204 q, for example, via the base station 404. The patient 506 a searchesthe database 504 for patient profiles also having cardiac conditionssimilar to that of patient 506. The social network system 204 q providesmultiple profiles of patients having similar conditions. The profilesinclude various data pertinent to each patient such as medicationtherapies, personal behavior histories, etc. The patient 506 requests acomparison of his medication therapy, medication therapy adherence, andbehavior to that listed in the profiled. The social network system 204 qprovides the requested comparative data in the form of a graphicaldisplay. From the display, the patient 506 is able to determine theprofiles having the most favorable treatment outcomes. From suchprofiles, the patient 506 and/or social network system 204 q analyze thedifferences between his medication, medication therapy adherence,behavior, etc. and the corresponding interdependencies of the profileshaving the most favorable treatment outcomes. The analysis may contrastthe differences found in various areas, as well as generate prescriptiveadvice, e.g., in which areas the patient 506 may want to adjust andspecific adjustments based on the analysis. The patient 506 may adoptthe prescriptive advice, i.e., adjust accordingly, to improve his ownpersonal outcome. Further, the patient 506 may update the social networksystem 204 q with the adjustment data, which may be used in the futurefor tracking personal improvement as well as benchmarking purposes byother individuals. In various aspects, the social network system 204 qmay be communicably associated with other web communities 106 h, e.g.,youth communities, business communities, etc.

3.0 IEM Data Framework Method

One aspect comprises, for example, receiving, via a hub, ingestibleevent data that originates from multiple ingested event markers; andcommunicating, via the hub, at least a portion of the ingestible eventmarker data to at least one ingestible event marker data system.

4.0 IEM Data Framework Article

One aspect comprises, for example, a storage medium having instructions,that when executed by a computing platform, result in execution of amethod of utilizing ingestible event marker data, comprising: receiving,via a hub, the ingestible event data that originates from multipleingested event markers; and communicating, via the hub, at least aportion of the ingestible event marker data to at least one ingestibleevent marker data system.

5.0 IEM Data Framework System

One aspect comprises, for example, a receive module to receive, via ahub, ingestible event data that originates from multiple ingested eventmarkers; and a communicate module to communicate, via the hub, at leasta portion of the ingestible event marker data to at least one ingestibleevent marker data system.

Further, any of the embodiments disclosed herein may be performed in adata processing system. To illustrate, a diagrammatic system comprises,for example, a processor, a main memory, a static memory, a bus, a videodisplay, an alpha-numeric input device, a cursor control device, a driveunit, a signal generation device, a network interface device, a machinereadable medium, instructions and a network, according to oneembodiment.

The diagrammatic system may indicate a personal computer and/or a dataprocessing system in which one or more operations disclosed herein maybe performed. The processor may be a microprocessor, a state machine, anapplication-specific integrated circuit, a field programmable gatearray, etc. The main memory may be a dynamic random access memory and/ora primary memory of a computer system. The static memory may be a harddrive, a flash drive, and/or other memory information associated withthe data processing system.

The bus may be an interconnection between various circuits and/orstructures of the data processing system. The video display may providegraphical representation of information on the data processing system.The alpha-numeric input device may be a keypad, a keyboard and I or anyother input device of text, e.g., a special device to aid the physicallychallenged. The cursor control device may be a pointing device such as amouse. The drive unit may be a hard drive, a storage system, and I orother longer term storage subsystem. The signal generation device may bea bios and I or a functional operating system of the data processingsystem. The network interface device may be a device that may performinterface functions such as code conversion, protocol conversion and/orbuffering required for communication to and from the network. Themachine readable medium may provide instructions on which any of themethods disclosed herein may be performed. The instructions may providesource code and I or data code to the processor to enable any one/ormore operations disclosed herein.

Although the present embodiments have been described with reference tospecific example embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the various embodiments.For example, the various devices, modules, etc. described herein may beenabled and operated using hardware circuitry, e.g., CMOS based logiccircuitry, firmware, software and/or any combination of hardware,firmware, and/or software, e.g., embodied in a machine readable medium.

For example, the various electrical structure and methods may beembodied using transistors, logic gates, and electrical circuits, e.g.,Application Specific Integrated circuitry (ASIC) and/or in DigitalSignal Processor (DSP) circuitry. For example, the receive module andthe communicate module and other modules may be enabled using one ormore of the technologies described herein.

In addition, it will be appreciated that the various operations,processes, and methods disclosed herein may be embodied in amachine-readable medium and I or a machine accessible medium compatiblewith a data processing system, e.g., a computer system, and may beperformed in any order. Accordingly, the specification and drawings areto be regarded in an illustrative rather than a restrictive sense.

Any or all data associated with the aforementioned devices and methods,for example, may be used alone or in combination with other data toconstitute IEM data, i.e., data having an IEM data aspect.

In certain embodiments, the system and I or method steps furtherincludes/utilizes an element for storing data, i.e., a data storageelement, where this element is present on an external device, such as abedside monitor, PDA, smart phone, computer server, etc. Typically, thedata storage element is a computer readable medium. The term “computerreadable medium” as used herein refers to any storage or transmissionmedium that participates in providing instructions and I or data to acomputer for execution and/or processing. Examples of storage mediainclude floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM orintegrated circuit, a magneto-optical disk, or a computer readable cardsuch as a PCMCIA card and the like, whether or not such devices areinternal or external to the computer. A file containing information maybe “stored” on a computer readable medium, where “storing” meansrecording information such that it is accessible and retrievable at alater data by a computer and I or computer-related component. Withrespect to computer readable media, “permanent memory” refers to memorythat is permanent. Permanent memory is not erased by termination of theelectrical supply to a computer of processor. Computer hard-drive ROM,i.e., not used as virtual memory, CD-ROM, floppy disk and DVD are allexamples of permanent memory. Random Access Memory (RAM) is an exampleof non-permanent memory. A file in permanent memory may be editable andre-writable.

Also provided are computer executable instructions, i.e., programming,for performing the above methods, e.g., for programming the IEM,receiver, and other components of the system. The computer executableinstructions are present on a computer readable medium. Accordingly,various aspects provide a computer readable medium containingprogramming for use in providing ingestible event marker data.

As such, in certain embodiments the systems include one or more of: adata storage element, a data processing element, a data display element,a data transmission element, a notification mechanism, and a userinterface. These elements may be present or otherwise associated with atleast one of the ingestible event marker data, the hub, and the IEM datasystems.

One of the above-described systems is reviewed in terms of a receivemodule and a communicate module. The aspects, however, are not solimited. In a broader sense, the systems are composed of two or moredifferent modules that communicate with each other, e.g., using the hubfunctionalities as reviewed above, e.g., using the IEM data in thecommunication, e.g., using the IEM data systems' functionalities.

It is to be understood that this invention is not limited to particularembodiments described, and as such may vary. It is also to be understoodthat the terminology used herein is for the purpose of describingparticular embodiments only, and is not intended to be limiting, sincethe scope of the present invention will be limited only by the appendedclaims.

Where a range of values is provided, it is understood that eachintervening value, to the tenth of the unit of the lower limit unlessthe context clearly dictates otherwise, between the upper and lowerlimit of that range and any other stated or intervening value in thatstated range, is encompassed within the invention. The upper and lowerlimits of these smaller ranges may independently be included in thesmaller ranges and are also encompassed within the invention, subject toany specifically excluded limit in the stated range. Where the statedrange includes one or both of the limits, ranges excluding either orboth of those included limits are also included in the invention.

Unless defined otherwise, all technical and scientific terms used hereinhave the same meaning as commonly understood by one of ordinary skill inthe art to which this invention belongs. Although any methods andmaterials similar or equivalent to those described herein can also beused in the practice or testing of the present invention, representativeillustrative methods and materials are now described.

All publications and patents cited in this specification are hereinincorporated by reference as if each individual publication or patentwere specifically and individually indicated to be incorporated byreference and are incorporated herein by reference to disclose anddescribe the methods and/or materials in connection with which thepublications are cited. The citation of any publication is for itsdisclosure prior to the filing date and should not be construed as anadmission that the present invention is not entitled to antedate suchpublication by virtue of prior invention. Further, the dates ofpublication provided may be different from the actual publication dateswhich may need to be independently confirmed.

It is noted that, as used herein and in the appended claims, thesingular forms “a”, “an”, and “the” include plural referents unless thecontext clearly dictates otherwise. It is further noted that the claimsmay be drafted to exclude any optional element. As such, this statementis intended to serve as antecedent basis for use of such exclusiveterminology as “solely,” “only” and the like in connection with therecitation of claim elements, or use of a “negative” limitation.

As will be apparent to those of skill in the art upon reading thisdisclosure, each of the individual embodiments described and illustratedherein has discrete components and features which may be readilyseparated from or combined with the features of any of the other severalembodiments without departing from the scope or spirit of the presentinvention. Any recited method can be carried out in the order of eventsrecited or in any other order which is logically possible.

Although the foregoing invention has been described in some detail byway of illustration and example for purposes of clarity ofunderstanding, it is readily apparent to those of ordinary skill in theart in light of the teachings of this invention that certain changes andmodifications may be made thereto without departing from the spirit orscope of the appended claims.

Accordingly, the preceding merely illustrates the principles of theinvention. It will be appreciated that those skilled in the art will beable to devise various arrangements which, although not explicitlydescribed or shown herein, embody the principles of the invention andare included within its spirit and scope. Furthermore, all examples andconditional language recited herein are principally intended to aid thereader in understanding the principles of the invention and the conceptscontributed by the inventors to furthering the art, and are to beconstrued as being without limitation to such specifically recitedexamples and conditions. Moreover, all statements herein recitingprinciples, aspects, and embodiments of the invention as well asspecific examples thereof, are intended to encompass both structural andfunctional equivalents thereof. Additionally, it is intended that suchequivalents include both currently known equivalents and equivalentsdeveloped in the future, i.e., any elements developed that perform thesame function, regardless of structure. The scope of the presentinvention, therefore, is not intended to be limited to the exemplaryembodiments shown and described herein. Rather, the scope and spirit ofpresent invention is embodied by the appended claims.

1.-26. (canceled)
 27. A system for generating a notification regardingmedication usage, the system comprising: a processor programmed to:receive data associated with a physiological pattern of an individual,wherein the data associated with the physiological pattern is encoded inan ingestible event marker (IEM) device and is derived from a signalgenerated by the IEM device after the IEM device has been ingested bythe individual; receive one or more measured data samples of aphysiologic parameter of the individual; compare the one or moremeasured data samples of the physiologic parameter to the dataassociated with the physiologic pattern derived from the IEM device; andgenerate a first electronic notification indicating whether theindividual ingested the IEM device based on the comparison between theone or more measured data samples of the physiologic parameter and thedata associated with the physiologic pattern.
 28. The system of claim27, wherein the physiologic pattern of the individual includes a heartrate variability, a breathing rate, or a heart rate.
 29. The system ofclaim 27, wherein the IEM device is configured to be ingested with themedication.
 30. The system of claim 27, wherein the processor is furtherprogrammed to: receive timing data from the signal generated by the IEMdevice, the timing data indicative of when the IEM device was ingested;compare the timing data to a dosing schedule associated with theindividual; and generate a second electronic notification indicatingwhether the individual ingested the IEM device in a timely manner. 31.The system of claim 27, wherein the processor is further programmed to:compute a total number of IEM devices ingested by the individual over atime period; and compare the total number of ingested IEM devices withprescription information associated with the individual.
 32. The systemof claim 31, wherein the processor is further configured to generate asecond electronic notification indicating whether a prescription refillis necessary based on the comparison between the total number ofingested IEM devices with prescription information.
 33. The system ofclaim 31, wherein the processor is further configured to generate asecond electronic notification indicating whether the individual isoverdosing based on the comparison between the total number of ingestedIEM devices with prescription information.
 34. The system of claim 27,wherein the processor is further programmed to receive data generated bythe IEM device identifying an ingested substance associated with the IEMdevice.
 35. The system of claim 31, wherein the processor is furtherconfigured to generate a second electronic notification to automaticallyrefill a prescription based on the comparison between the total numberof ingested IEM devices with prescription information.
 36. The system ofclaim 27, wherein the processor is further configured to cause displayof medical information including whether the individual ingested the IEMdevice.
 37. The system of claim 36, wherein the medical furthercomprises a recommendation for how to improve the individual's health.38. The system of claim 27, wherein the processor is further configuredto generate a second notification providing a reminder for theindividual to ingest a subsequent IEM device at a prescribed time. 39.The system of claim 27, wherein the processor is further configured to:analyze the one or more measured data samples of a physiologic parameterof the individual; and generate a second notification indicating anefficacy of the ingested IEM device, based on the analysis of the one ormore measured data samples and the indication of whether the individualingested the IEM device.
 40. The system of claim 39, wherein theprocessor is further configured to initiate a scheduled appointment to aphysician, based on the analysis of the one or more measured datasamples and the indication of whether the individual ingested the IEMdevice.
 41. The system of claim 27, wherein the processor is furtherconfigured to generate a second notification providing an inventive forthe individual to ingest a subsequent IEM device at a prescribed time.42. The system of claim 27, wherein the processor is further configuredto generate a second notification to a regulatory agency providinginformation about a controlled substance associated with the IEM device.43. The system of claim 27, wherein the processor is further configuredto generate a second notification to a social networking systemproviding notification of the individual's activity related to ingestingthe IEM device.